{"id":415820,"date":"2024-06-30T00:35:45","date_gmt":"2024-06-30T00:35:45","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=415820"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=415820","title":{"rendered":"PostgreSQL 16: Part 3 or CommitFest 2022-11<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

\"image\"<\/p>\n

<\/p>\n

We continue to follow the news of the upcoming PostgreSQL 16. The third CommitFest concluded in early December. Let’s look at the results.<\/p>\n

<\/p>\n

If you missed the previous CommitFests, check out our reviews: 2022-07<\/a>, 2022-09<\/a>.<\/p>\n

<\/p>\n

Here are the patches I want to talk about:<\/p>\n

<\/p>\n

meson: a new source code build system<\/a>
Documentation: a new chapter on transaction processing<\/a>
psql: \\d+ indicates foreign partitions in a partitioned table<\/a>
psql: extended query protocol support<\/a>
Predicate locks on materialized views<\/a>
Tracking last scan time of indexes and tables<\/a>
pg_buffercache: a new function pg_buffercache_summary<\/a>
walsender displays the database name in the process status<\/a>
Reducing the WAL overhead of freezing tuples<\/a>
Reduced power consumption when idle<\/a>
postgres_fdw: batch mode for COPY<\/a>
Modernizing the GUC infrastructure<\/a>
Hash index build optimization<\/a>
MAINTAIN \u2015 a new privilege for table maintenance<\/a>
SET ROLE: better role change management<\/a>
Support for file inclusion directives in pg_hba.conf and pg_ident.conf<\/a>
Regular expressions support in pg_hba.conf<\/a><\/p>\n

<\/a>
<\/a> <\/p>\n

meson: a new source code build system<\/a><\/strong>
commit: e6927270<\/a>, 4c72102e<\/a><\/p>\n

<\/p>\n

Meson support was first introduced in a commit way back in September. Several dozen more commits followed. Several dozens more followed. In early December, a documentation section<\/a> describing the new build process was committed. There is also a wiki page<\/a> that explains, among other things, what was behind the decision to introduce the new building tool. One of the reasons is to simplify building the server for Windows systems and to be able to eventually stop supporting the PostgreSQL’s own build tools from the \/src\/tools\/msvc entirely.<\/p>\n

<\/p>\n

The new build system will be available alongside with autoconf and make, there is no plans to replace the good old tools.<\/p>\n

<\/p>\n

However, I specifically used Meson to build the fresh PostgreSQL 16 testing environment for this article. On Ubuntu, the building went as follows:<\/p>\n

<\/p>\n

$ git clone git:\/\/git.postgresql.org\/git\/postgresql.git $ cd postgresql $ meson setup build --prefix=\/home\/pal\/pg16 -Dpgport=5416 $ cd build $ ninja $ ninja install<\/code><\/pre>\n
  <\/p>\n
I left everything on default, except for the installation location and the server port.<\/p>\n
  <\/p>\n
All what’s left is to initialize the cluster and start the server, which you do the same way regardless of the build tool used.<\/p>\n
  <\/a>  <\/p>\n
Documentation: a new chapter on transaction processing<\/a><\/strong>
  commit: 66bc9d2d<\/a><\/p>\n
  <\/p>\n
A new chapter has been added to the documentation: 74. Transaction processing<\/a>. It lives in the Internals section and gives a brief overview of what virtual and real transaction identifiers are, how they are shown in pg_locks, and how subtransactions and two-phase transactions work.<\/p>\n
  <\/a>  <\/p>\n
psql: \\d+ indicates foreign partitions in a partitioned table<\/a><\/strong>
  commit: bd95816f<\/a><\/p>\n
  <\/p>\n
For a partitioned table, the \\d+ command will mark sections that are foreign tables with the word FOREIGN.<\/p>\n
  <\/p>\n
\\d+ data<\/code><\/pre>\n
  <\/p>\n
                                    Partitioned table \"public.data\"   Column   | Type | Collation | Nullable | Default | Storage  | Compression | Stats target | Description -----------+------+-----------+----------+---------+----------+-------------+--------------+-------------  data_year | text |           |          |         | extended |             |              | Partition key: LIST (data_year) Partitions: data_2020 FOR VALUES IN ('2020'), FOREIGN,             data_2021 FOR VALUES IN ('2021'), FOREIGN,             data_2022 FOR VALUES IN ('2022')<\/code><\/pre>\n
  <\/a>  <\/p>\n
psql: extended query protocol support<\/a><\/strong>
  commit: 5b66de34<\/a><\/p>\n
  <\/p>\n
Until now, psql has not directly supported the extended query protocol<\/a>. Therefore, parameterized queries could only be performed indirectly, such as with the PREPARE statement.<\/p>\n
  <\/p>\n
Now the \\bind command has been added to psql to bind values to the parameters of the next query. Here’s how it works:<\/p>\n
  <\/p>\n
SET log_statement='all';  \\bind 42 'Answer: '  SELECT $2||$1;<\/code><\/pre>\n
  <\/p>\n
  ?column?   ------------ Answer: 42 (1 row)<\/code><\/pre>\n
  <\/p>\n
\\! tail -2 logfile<\/code><\/pre>\n
  <\/p>\n
2022-12-05 12:58:05.924 MSK [16566] LOG:  execute <unnamed>: SELECT $2||$1; 2022-12-05 12:58:05.924 MSK [16566] DETAIL:  parameters: $1 = '42', $2 = 'Answer: '<\/code><\/pre>\n
  <\/p>\n
Only a fraction of the capabilities of the extended query protocol has been implemented, but the initiative is very welcome.<\/p>\n
  <\/a>  <\/p>\n
Predicate locks on materialized views<\/a><\/strong>
  commit: 43351557<\/a><\/p>\n
  <\/p>\n
Predicate locks are used to ensure consistency for transactions with the SERIALIZABLE isolation level. They were never designed to update materialized views with the REFRESH MATERIALIZED VIEW command, because it exclusively locks the view in order to prevent any concurrent access anomalies.<\/p>\n
  <\/p>\n
But when updating with the CONCURRENTLY parameter and without predicate locks, transactions with the SERIALIZABLE isolation level could experience write skew. Now the problem is fixed.<\/p>\n
  <\/a>  <\/p>\n
Tracking last scan time of indexes and tables<\/a><\/strong>
  commit: c0374718<\/a><\/p>\n
  <\/p>\n
In addition to counting table and index scans, the cumulative statistics system now records time and date of the last recorded scan. This data is stored in the last_seq_scan and last_idx_scan columns in pg_stat_all_tables and the last_idx_scan column in pg_stat_all_indexes.<\/p>\n
  <\/p>\n
SELECT seq_scan, last_seq_scan, idx_scan, last_idx_scan FROM   pg_stat_all_tables WHERE  relid = 'tickets'::regclass;<\/code><\/pre>\n
  <\/p>\n
 seq_scan |         last_seq_scan         | idx_scan |         last_idx_scan          ----------+-------------------------------+----------+-------------------------------         23 | 2022-12-07 15:17:57.261575+03 |        2 | 2022-12-05 14:59:53.564968+03 (1 row)<\/code><\/pre>\n
  <\/p>\n
SELECT indexrelname, idx_scan, last_idx_scan FROM pg_stat_all_indexes WHERE relid = 'tickets'::regclass;<\/code><\/pre>\n
  <\/p>\n
     indexrelname     | idx_scan |         last_idx_scan          ----------------------+----------+-------------------------------  tickets_pkey         |        2 | 2022-12-05 14:59:53.564968+03  tickets_book_ref_idx |        0 | (2 rows)<\/code><\/pre>\n
  <\/p>\n
It can be helpful for analyzing index and table use if no dedicated monitoring system is implemented.<\/p>\n
  <\/a>  <\/p>\n
pg_buffercache: a new function pg_buffercache_summary<\/a><\/strong>
  commit: 2589434a<\/a><\/p>\n
  <\/p>\n
The pg_buffercache extension now can display aggregated buffer cache data:<\/p>\n
  <\/p>\n
CREATE EXTENSION pg_buffercache;  SELECT * FROM pg_buffercache_summary()\\gx<\/code><\/pre>\n
  <\/p>\n
-[ RECORD 1 ]--+------------------ buffers_used   | 2544 buffers_unused | 13840 buffers_dirty  | 38 buffers_pinned | 0 usagecount_avg | 2.183176100628931<\/code><\/pre>\n
  <\/p>\n
We used to obtain this data by aggregating the pg_buffercache view, but the new function does not lock the buffers, therefore it is cheaper and can be easily integrated into monitoring systems.<\/p>\n
  <\/a>  <\/p>\n
walsender displays the database name in the process status<\/a><\/strong>
  commit: af205152<\/a><\/p>\n
  <\/p>\n
walsender is the process that handles replication protocol connections. For physical replication or backup, walsender connects to an instance, but not to a specific database. When you create a logical replication subscription, however, the publisher creates a logical replication slot, and walsender connects to the database where the publication is created.<\/p>\n
  <\/p>\n
The patch adds the name of the database to walsender process description in case of logical replication, which makes monitoring those processes more convenient.<\/p>\n
  <\/p>\n
16(sub)=# CREATE SUBSCRIPTION sub CONNECTION 'port=5416 user=postgres dbname=demo' PUBLICATION pub;<\/code><\/pre>\n
  <\/p>\n
NOTICE:  created replication slot \"sub\" on publisher CREATE SUBSCRIPTION<\/code><\/pre>\n
  <\/p>\n
16(pub)=# \\! ps -o pid,command --ppid `head -n 1 \/home\/pal\/pg16\/data\/postmaster.pid`<\/code><\/pre>\n
  <\/p>\n
    PID COMMAND   38514 postgres: checkpointer   38515 postgres: background writer   38517 postgres: walwriter   38518 postgres: autovacuum launcher   38519 postgres: logical replication launcher   38522 postgres: postgres demo [local] idle   38662 postgres: walsender postgres demo [local] START_REPLICATION<\/code><\/pre>\n
  <\/p>\n
Here, the walsender process status displays the demo database name.<\/p>\n
  <\/a>  <\/p>\n
Reducing the WAL overhead of freezing tuples<\/a><\/strong>
  commit: 9e540599<\/a><\/p>\n
  <\/p>\n
Peter Geoghegan is working<\/a> on proactive tuple freezing. The purpose is clear: to avoid transaction counter wraparound, you need to start freezing in advance. However, an earlier freeze leads to a larger WAL volume and increases the associated overhead (WAL replication and archiving).<\/p>\n
  <\/p>\n
In this patch, Peter proposed to form WAL freezing records more compactly (~5 times so).<\/p>\n
  <\/a>  <\/p>\n
Reduced power consumption when idle<\/a><\/strong>
  commit: cd4329d9<\/a>, 05a7be93<\/a><\/p>\n
  <\/p>\n
When the main server is idle, the startup process on physical replicas still wakes up every 5 seconds to check if the file specified in the promote_trigger_file<\/em> has appeared. But there are other mechanisms for promoting a replica: pg_ctl promote and the pg_promote function. To reduce resource consumption for such wake-ups, the promote_trigger_file<\/em> parameter was removed.<\/p>\n
  <\/p>\n
Similar work<\/a> was done with the walreceiver process, which woke up 10 times a second, checking whether it needed to do something. Now, the process calculates the time of its next start in advance.<\/p>\n
  <\/a>  <\/p>\n
postgres_fdw: batch mode for COPY<\/a><\/strong>
  commit: 97da4824<\/a><\/p>\n
  <\/p>\n
Batch-inserting records into foreign tables first became possible<\/a> in the 14th release. The batch size is set by the batch_size parameter at the foreign server or table level. However, it was implemented only for the INSERT command. This patch adds support for batch paste mode for the COPY FROM command.<\/p>\n
  <\/p>\n
Let’s compare the insertion speed by different commands. To do this, I first create an empty bookings table in the postgres database, into which we will insert data.<\/p>\n
  <\/p>\n
postgres=# CREATE TABLE public.bookings (     book_ref char(6),     book_date timestamptz,     total_amount numeric(10,2) );<\/code><\/pre>\n
  <\/p>\n
In the demo database in the same cluster, let’s create a foreign table for the bookings table.<\/p>\n
  <\/p>\n
CREATE EXTENSION postgres_fdw;  CREATE SERVER srv     FOREIGN DATA WRAPPER postgres_fdw     OPTIONS (dbname 'postgres', batch_size '1');  CREATE USER MAPPING FOR postgres     SERVER srv     OPTIONS (user 'postgres');  CREATE FOREIGN TABLE bookings_remote (     book_ref char(6),     book_date timestamptz,     total_amount numeric(10,2)  ) SERVER srv      OPTIONS (schema_name 'public', table_name 'bookings');<\/code><\/pre>\n
  <\/p>\n
The batch size is set at the server level as 1, which means that the batch mode is disabled and records are sent one at a time.<\/p>\n
  <\/p>\n
Let’s dump the bookings table contents from the demo database<\/a> into a file:<\/p>\n
  <\/p>\n
\\COPY bookings TO 'bookings.txt'<\/code><\/pre>\n
  <\/p>\n
Now, upload the file contents into the foreign table and measure the time:<\/p>\n
  <\/p>\n
\\timing on \\COPY bookings_remote FROM 'bookings.txt'<\/code><\/pre>\n
  <\/p>\n
COPY 2111110 Time: 57327,152 ms (00:57,327)<\/code><\/pre>\n
  <\/p>\n
It took almost a minute to insert a little more than two million rows. Set the batch size to 100 and repeat the test:<\/p>\n
  <\/p>\n
TRUNCATE bookings_remote; ALTER SERVER srv OPTIONS (SET batch_size '100');  \\COPY bookings_remote FROM 'bookings.txt'<\/code><\/pre>\n
  <\/p>\n
COPY 2111110 Time: 8780,000 ms (00:08,780)<\/code><\/pre>\n
  <\/p>\n
The insertion speed has increased by more than 6 times!<\/p>\n
  <\/p>\n
Curiously, the INSERT command works even faster in batch mode:<\/p>\n
  <\/p>\n
TRUNCATE bookings_remote; INSERT INTO bookings_remote SELECT * FROM bookings;<\/code><\/pre>\n
  <\/p>\n
INSERT 0 2111110 Time: 6669,504 ms (00:06,670)<\/code><\/pre>\n
  <\/p>\n
So when it comes to insertion with the COPY command, there’s room for optimization yet! Also, it would be great to teach postgres_fdw to use batch mode to modify and delete rows, not just read and insert.<\/p>\n
  <\/a>  <\/p>\n
Modernizing the GUC infrastructure<\/a><\/strong>
  commit: f13b2088<\/a>, 3057465a<\/a>, 407b50f2<\/a>, 9c911ec0<\/a><\/p>\n
  <\/p>\n
This series of commits optimizes storage and speeds up access to configuration parameters, including user-generated ones.<\/p>\n
  <\/p>\n
The optimization is most evident in the example that Tom Lane gave in the letter that started the discussion:<\/p>\n
  <\/p>\n
do $$     begin         for i in 1..10000 loop         perform set_config('foo.bar' || i::text, i::text, false);     end loop; end $$;<\/code><\/pre>\n
  <\/p>\n
On my computer, creating ten thousand user parameters in PostgreSQL 15 took about six seconds, and after applying the patches, the time was reduced to ~ 30 milliseconds.<\/p>\n
  <\/a>  <\/p>\n
Hash index build optimization<\/a><\/strong>
  commit: e09d7a12<\/a>, d09dbeb9<\/a><\/p>\n
  <\/p>\n
When building hash indexes, the values were sorted only by the bucket number. If you additionally sort by value, then inserting subsequent values is faster.<\/p>\n
  <\/p>\n
The first commit was made in July, and the second in November. By now, the hash index build speed increased by 5-15%.<\/p>\n
  <\/a>  <\/p>\n
MAINTAIN \u2015 a new privilege for table maintenance<\/a><\/strong>
  commit: 60684dd8<\/a><\/p>\n
  <\/p>\n
A number of maintenance actions for tables and materialized views are not regulated by privileges and are usually available only to the object owner and the superuser.<\/p>\n
  <\/p>\n
PostgreSQL 16 introduces the MAINTAIN privilege, which can be granted on materialized views and tables, including system ones:<\/p>\n
  <\/p>\n
GRANT MAINTAIN ON pg_class, pg_attribute, pg_type TO alice;<\/code><\/pre>\n
  <\/p>\n
The \\dp output uses the m character for this privilege:<\/p>\n
  <\/p>\n
\\dp pg_catalog.pg_class                                      Access privileges    Schema   |   Name   | Type  |     Access privileges      | Column privileges | Policies ------------+----------+-------+----------------------------+-------------------+----------  pg_catalog | pg_class | table | postgres=arwdDxtm\/postgres+|                   |             |          |       | =r\/postgres               +|                   |             |          |       | alice=m\/postgres           |                   |<\/code><\/pre>\n
  <\/p>\n
What actions are granted by this privilege? These include executing the commands ANALYZE, VACUUM (including VACUUM FULL), CLUSTER, REINDEX, REFRESH MATERIALIZED VIEW and LOCK TABLE.<\/p>\n
  <\/p>\n
In addition, a predefined pg_maintain role has been added. Membership in this role grants the MAINTAIN privilege on all relations in the database. This allows you to grant maintenance privileges to a regular role that does not have the rights to perform DDL and DML operations in the database otherwise.<\/p>\n
  <\/p>\n
The initial patch proposed the addition of two privileges for VACUUM and ANALYZE, but eventually the community settled on the MAINTAIN privilege with more extensive maintenance capabilities.<\/p>\n
  <\/a>  <\/p>\n
SET ROLE: better role change management<\/a><\/strong>
  commit: 3d14e171<\/a><\/p>\n
  <\/p>\n
This patch continues the effort to build a more robust roles and privileges management system. The previous article talked about granting membership in roles<\/a> and inheriting privileges<\/a>.<\/p>\n
  <\/p>\n
The new patch introduces switching to another role with the SET ROLE command. Suppose we decide to include the alice role into pg_read_all_data with privilege inheritance enabled:<\/p>\n
  <\/p>\n
postgres=# GRANT pg_read_all_data TO alice WITH INHERIT TRUE;<\/code><\/pre>\n
  <\/p>\n
The alice role can now use pg_read_all_data privileges. But nothing is stopping alice from switching role to pg_read_all_data and starting to create objects on its behalf:<\/p>\n
  <\/p>\n
postgres=# \\c - alice<\/code><\/pre>\n
  <\/p>\n
You are now connected to database \"postgres\" as user \"alice\".<\/code><\/pre>\n
  <\/p>\n
alice=> CREATE TABLE t (id int);<\/code><\/pre>\n
  <\/p>\n
CREATE TABLE<\/code><\/pre>\n
  <\/p>\n
alice=> \\dt t<\/code><\/pre>\n
  <\/p>\n
            List of relations  Schema | Name | Type  |      Owner        --------+------+-------+------------------  public | t    | table | pg_read_all_data<\/code><\/pre>\n
  <\/p>\n
Actually, there is. To create objects, the pg_read_all_data role must have the CREATE privilege in some schema, such as in public. And starting from PostgreSQL 15, the pseudo-role public no longer has this privilege. As for the example above, I had to run the following command in advance:<\/p>\n
  <\/p>\n
postgres=# GRANT CREATE ON SCHEMA public TO public;<\/code><\/pre>\n
  <\/p>\n
Nevertheless, switching to another role may be undesirable in certain situations. If we provided membership in a role with INHERIT TRUE, then why switch at all? In the new version, this can be prohibited by the same GRANT command:<\/p>\n
  <\/p>\n
postgres=# GRANT pg_read_all_data TO alice WITH INHERIT TRUE, SET FALSE;<\/code><\/pre>\n
  <\/p>\n
Alice can now use pg_read_all_data privileges, but will not be able to switch to it.<\/p>\n
  <\/p>\n
alice=> SET ROLE pg_read_all_data;<\/code><\/pre>\n
  <\/p>\n
ERROR:  permission denied to set role \"pg_read_all_data\"<\/code><\/pre>\n
  <\/p>\n
The ability to switch to a role is stored in the set_option column of the pg_auth_members table, next to inherit_option and admin_option.<\/p>\n
  <\/p>\n
SELECT roleid::regrole, member::regrole, grantor::regrole,        admin_option, inherit_option, set_option FROM pg_auth_members WHERE member = 'alice'::regrole\\gx<\/code><\/pre>\n
  <\/p>\n
-[ RECORD 1 ]--+----------------- roleid         | pg_read_all_data member         | alice grantor        | postgres admin_option   | f inherit_option | t set_option     | f<\/code><\/pre>\n
  <\/a>  <\/p>\n
Support for file inclusion directives in pg_hba.conf and pg_ident.conf<\/a><\/strong>
  commit: a54b658c<\/a><\/p>\n
  <\/p>\n
The configuration files pg_hba.conf and pg_ident.conf, as well as postgresql.conf, now support the directives to include other files: include, include_if_exists, include_dir.<\/p>\n
  <\/p>\n
Columns containing the file name and rule\/map number have been added to pg_hba_file_rules and pg_ident_file_mappings:<\/p>\n
  <\/p>\n
SELECT * FROM pg_hba_file_rules WHERE file_name LIKE '%hba_ident_test.conf' \\gx<\/code><\/pre>\n
  <\/p>\n
-[ RECORD 1 ]--------------------------------- rule_number | 1 file_name   | \/home\/pal\/pg\/hba_ident_test.conf line_number | 1 type        | local database    | {all} user_name   | {alice} address     | netmask     | auth_method | peer options     | {map=m1} error       |  ```PGSQL SELECT * FROM pg_ident_file_mappings WHERE file_name LIKE '%ident_test.conf' \\gx<\/code><\/pre>\n
  <\/p>\n
-[ RECORD 1 ]----------------------------- map_number  | 1 file_name   | \/home\/pal\/pg\/ident_test.conf line_number | 1 map_name    | m1 sys_name    | student pg_username | alice error       |<\/code><\/pre>\n
  <\/a>  <\/p>\n
Regular expressions support in pg_hba.conf<\/a><\/strong>
  commit: 8fea8683<\/a>, a9039713<\/a>, fc579e11<\/a><\/p>\n
  <\/p>\n
pg_hba.conf supports regular expressions for the user name and the database name. If any of these fields starts with a slash (\/), then the value is considered a regular expression.<\/p>\n
  <\/p>\n\n
  <\/p>\n
This is all for now. Looking forward to the results of the January CommitFest<\/a>!<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n

 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/articles\/708082\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
<\/div>\n
\n
\n
\n
\n
\"image\"<\/p>\n
  <\/p>\n
We continue to follow the news of the upcoming PostgreSQL 16. The third CommitFest concluded in early December. Let’s look at the results.<\/p>\n
  <\/p>\n
If you missed the previous CommitFests, check out our reviews: 2022-07<\/a>, 2022-09<\/a>.<\/p>\n
  <\/p>\n
Here are the patches I want to talk about:<\/p>\n
  <\/p>\n
meson: a new source code build system<\/a>
  Documentation: a new chapter on transaction processing<\/a>
  psql: \\d+ indicates foreign partitions in a partitioned table<\/a>
  psql: extended query protocol support<\/a>
  Predicate locks on materialized views<\/a>
  Tracking last scan time of indexes and tables<\/a>
  pg_buffercache: a new function pg_buffercache_summary<\/a>
  walsender displays the database name in the process status<\/a>
  Reducing the WAL overhead of freezing tuples<\/a>
  Reduced power consumption when idle<\/a>
  postgres_fdw: batch mode for COPY<\/a>
  Modernizing the GUC infrastructure<\/a>
  Hash index build optimization<\/a>
  MAINTAIN \u2015 a new privilege for table maintenance<\/a>
  SET ROLE: better role change management<\/a>
  Support for file inclusion directives in pg_hba.conf and pg_ident.conf<\/a>
  Regular expressions support in pg_hba.conf<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-415820","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/415820","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=415820"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/415820\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=415820"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=415820"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=415820"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}