PostgreSQL 12.7 (upcoming) commit log

Clarify the usage of max_replication_slots on the subscriber side.

commit   : c267ca682803f8ca233076d216fba18b635238a6    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Mar 2021 10:30:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Mar 2021 10:30:27 +0530    

Click here for diff

It was not clear in the docs that the max_replication_slots is also used  
to track replication origins on the subscriber side.  
  
Author: Paul Martinez  
Reviewed-by: Amit Kapila  
Backpatch-through: 10 where logical replication was introduced  
Discussion: https://postgr.es/m/CACqFVBZgwCN_pHnW6dMNCrOS7tiHCw6Retf_=U2Vvj3aUSeATw@mail.gmail.com  

M doc/src/sgml/config.sgml
M doc/src/sgml/logical-replication.sgml

Use native path separators to pg_ctl in initdb

commit   : f927767919e8d7079043d637d2177b554126ad6c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 2 Mar 2021 15:39:34 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 2 Mar 2021 15:39:34 -0300    

Click here for diff

On Windows, CMD.EXE allegedly does not run a command that uses forward slashes,  
so let's convert the path to use backslashes instead.  
  
Backpatch to 10.  
  
Author: Nitin Jadhav <nitinjadhavpostgres@gmail.com>  
Reviewed-by: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>  
Discussion: https://postgr.es/m/CAMm1aWaNDuaPYFYMAqDeJrZmPtNvLcJRS++CcZWY8LT6KcoBZw@mail.gmail.com  

M src/bin/initdb/initdb.c

Fix duplicated test case in TAP tests of reindexdb

commit   : 0f1b0c0b60ef7b56bbccacd4307fdda8afa1a59b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Mar 2021 13:19:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Mar 2021 13:19:11 +0900    

Click here for diff

The same test for REINDEX (VERBOSE) was done twice, while it is clear  
that the second test should use --concurrently.  Issue introduced in  
5dc92b8, for what looks like a copy-paste mistake.  
  
Reviewed-by: Mark Dilger  
Discussion: https://postgr.es/m/A7AE97EA-F4B0-4CAB-8FFF-3FECD31F9D63@enterprisedb.com  
Backpatch-through: 12  

M src/bin/scripts/t/090_reindexdb.pl

Fix use-after-free bug with AfterTriggersTableData.storeslot

commit   : 262eb990c72097bd804e5c747fe38bf9b3a1ded9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 27 Feb 2021 18:09:15 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 27 Feb 2021 18:09:15 -0300    

Click here for diff

AfterTriggerSaveEvent() wrongly allocates the slot in execution-span  
memory context, whereas the correct thing is to allocate it in  
a transaction-span context, because that's where the enclosing  
AfterTriggersTableData instance belongs into.  
  
Backpatch to 12 (the test back to 11, where it works well with no code  
changes, and it's good to have to confirm that the case was previously  
well supported); this bug seems introduced by commit ff11e7f4b9ae.  
  
Reported-by: Bertrand Drouvot <bdrouvot@amazon.com>  
Author: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/39a71864-b120-5a5c-8cc5-c632b6f16761@amazon.com  

M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql

Doc: further clarify libpq's description of connection string URIs.

commit   : fb1e218cb07e9b78a26d52d1c7fc03f5ce8691eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Feb 2021 15:24:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Feb 2021 15:24:01 -0500    

Click here for diff

Break the synopsis into named parts to make it less confusing.  
Make more than zero effort at applying SGML markup.  Do a bit  
of copy-editing of nearby text.  
  
The synopsis revision is by Alvaro Herrera and Paul Förster,  
the rest is my fault.  Back-patch to v10 where multi-host  
connection strings appeared.  
  
Discussion: https://postgr.es/m/6E752D6B-487C-463E-B6E2-C32E7FB007EA@gmail.com  

M doc/src/sgml/libpq.sgml

doc: Mention PGDATABASE as supported by pgbench

commit   : 9e9b5c05010d25e16e04c8c282a52626650ae233    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Feb 2021 16:07:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Feb 2021 16:07:08 +0900    

Click here for diff

PGHOST, PGPORT and PGUSER were already mentioned, but not PGDATABASE.  
Like 5aaa584, backpatch down to 12.  
  
Reported-by: Christophe Courtois  
Discussion: https://postgr.es/m/161399398648.21711.15387267201764682579@wrigleys.postgresql.org  
Backpatch-through: 12  

M doc/src/sgml/ref/pgbench.sgml

Fix some typos, grammar and style in docs and comments

commit   : 3b2af88788e1e136bcde78b74ff7387b0c58488a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Feb 2021 16:14:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Feb 2021 16:14:00 +0900    

Click here for diff

The portions fixing the documentation are backpatched where needed.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20210210235557.GQ20012@telsasoft.com  
backpatch-through: 9.6  

M doc/src/sgml/charset.sgml
M doc/src/sgml/pageinspect.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/ref/create_type.sgml
M doc/src/sgml/ref/drop_index.sgml
M doc/src/sgml/rules.sgml

Reinstate HEAP_XMAX_LOCK_ONLY|HEAP_KEYS_UPDATED as allowed

commit   : 2796ae2ad25330e80e97e823aa72091a9374d87d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Feb 2021 17:30:21 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Feb 2021 17:30:21 -0300    

Click here for diff

Commit 866e24d47db1 added an assert that HEAP_XMAX_LOCK_ONLY and  
HEAP_KEYS_UPDATED cannot appear together, on the faulty assumption that  
the latter necessarily referred to an update and not a tuple lock; but  
that's wrong, because SELECT FOR UPDATE can use precisely that  
combination, as evidenced by the amcheck test case added here.  
  
Remove the Assert(), and also patch amcheck's verify_heapam.c to not  
complain if the combination is found.  Also, out of overabundance of  
caution, update (across all branches) README.tuplock to be more explicit  
about this.  
  
Author: Julien Rouhaud <rjuju123@gmail.com>  
Reviewed-by: Mahendra Singh Thalor <mahi6run@gmail.com>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Discussion: https://postgr.es/m/20210124061758.GA11756@nol  

M src/backend/access/heap/README.tuplock

Fix psql's ON_ERROR_ROLLBACK so that it handles COMMIT AND CHAIN.

commit   : 67b3ee292935352b4b12b7a1bce17c64f85ce32e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Feb 2021 22:01:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Feb 2021 22:01:25 +0900    

Click here for diff

When ON_ERROR_ROLLBACK is enabled, psql releases a temporary savepoint  
if it's idle in a valid transaction block after executing a query. But psql  
doesn't do that after RELEASE or ROLLBACK is executed because a temporary  
savepoint has already been destroyed in that case.  
  
This commit changes psql's ON_ERROR_ROLLBACK so that it doesn't release  
a temporary savepoint also when COMMIT AND CHAIN is executed. A temporary  
savepoint doesn't need to be released in that case because  
COMMIT AND CHAIN also destroys any savepoints defined within the transaction  
to commit. Otherwise psql tries to release the savepoint that  
COMMIT AND CHAIN has already destroyed and cause an error  
"ERROR:  savepoint "pg_psql_temporary_savepoint" does not exist".  
  
Back-patch to v12 where transaction chaining was added.  
  
Reported-by: Arthur Nascimento  
Author: Arthur Nascimento  
Reviewed-by: Fujii Masao, Vik Fearing  
Discussion: https://postgr.es/m/16867-3475744069228158@postgresql.org  

M src/bin/psql/common.c

Fix bug in COMMIT AND CHAIN command.

commit   : fadcc4e81bd99e6032ae042cae53be0c6eea7580    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Feb 2021 21:57:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Feb 2021 21:57:52 +0900    

Click here for diff

This commit fixes COMMIT AND CHAIN command so that it starts new transaction  
immediately even if savepoints are defined within the transaction to commit.  
Previously COMMIT AND CHAIN command did not in that case because  
commit 280a408b48 forgot to make CommitTransactionCommand() handle  
a transaction chaining when the transaction state was TBLOCK_SUBCOMMIT.  
  
Also this commit adds the regression test for COMMIT AND CHAIN command  
when savepoints are defined.  
  
Back-patch to v12 where transaction chaining was added.  
  
Reported-by: Arthur Nascimento  
Author: Fujii Masao  
Reviewed-by: Arthur Nascimento, Vik Fearing  
Discussion: https://postgr.es/m/16867-3475744069228158@postgresql.org  

M src/backend/access/transam/xact.c
M src/test/regress/expected/transactions.out
M src/test/regress/sql/transactions.sql

Fix another ancient bug in parsing of BRE-mode regular expressions.

commit   : e7cddb5f29171a536233acecb7ac9b9c5e1b4c77    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Feb 2021 22:38:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Feb 2021 22:38:55 -0500    

Click here for diff

While poking at the regex code, I happened to notice that the bug  
squashed in commit afcc8772e had a sibling: next() failed to return  
a specific value associated with the '}' token for a "\{m,n\}"  
quantifier when parsing in basic RE mode.  Again, this could result  
in treating the quantifier as non-greedy, which it never should be in  
basic mode.  For that to happen, the last character before "\}" that  
sets "nextvalue" would have to set it to zero, or it'd have to have  
accidentally been zero from the start.  The failure can be provoked  
repeatably with, for example, a bound ending in digit "0".  
  
Like the previous patch, back-patch all the way.  

M src/backend/regex/regc_lex.c

Fix typo

commit   : 6a31b48ec88ae506c6f115948c86f61abb89a89a    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 17 Feb 2021 13:53:26 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 17 Feb 2021 13:53:26 +0100    

Click here for diff

Author: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/0CF087FC-BEAD-4010-8BB9-3CDD74DC9060@yesql.se  

M doc/src/sgml/ref/create_table.sgml

Make ExecGetInsertedCols() and friends more robust and improve comments.

commit   : 2b81444a88cc499f5d3608c5943e9a6e4b489070    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 15 Feb 2021 09:28:08 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 15 Feb 2021 09:28:08 +0200    

Click here for diff

If ExecGetInsertedCols(), ExecGetUpdatedCols() or ExecGetExtraUpdatedCols()  
were called with a ResultRelInfo that's not in the range table and isn't a  
partition routing target, the functions would dereference a NULL pointer,  
relinfo->ri_RootResultRelInfo. Such ResultRelInfos are created when firing  
RI triggers in tables that are not modified directly. None of the current  
callers of these functions pass such relations, so this isn't a live bug,  
but let's make them more robust.  
  
Also update comment in ResultRelInfo; after commit 6214e2b228,  
ri_RangeTableIndex is zero for ResultRelInfos created for partition tuple  
routing.  
  
Noted by Coverity. Backpatch down to v11, like commit 6214e2b228.  
  
Reviewed-by: Tom Lane, Amit Langote  

M src/backend/executor/execUtils.c
M src/include/nodes/execnodes.h

Default to wal_sync_method=fdatasync on FreeBSD.

commit   : a27f3a7f4159c5afaf33932df16ca4fed6689c06    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Feb 2021 15:43:39 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Feb 2021 15:43:39 +1300    

Click here for diff

FreeBSD 13 gained O_DSYNC, which would normally cause wal_sync_method to  
choose open_datasync as its default value.  That may not be a good  
choice for all systems, and performs worse than fdatasync in some  
scenarios.  Let's preserve the existing default behavior for now.  
  
Like commit 576477e73c4, which did the same for Linux, back-patch to all  
supported releases.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLsAMXBQrCxCXoW-JsUYmdOL8ALYvaX%3DCrHqWxm-nWbGA%40mail.gmail.com  

M doc/src/sgml/config.sgml
M src/backend/utils/misc/postgresql.conf.sample
M src/include/port/freebsd.h

Hold interrupts while running dsm_detach() callbacks.

commit   : 840eda04ebc99ce211ffd11946a59ad43c42bfa6    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Feb 2021 13:32:58 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Feb 2021 13:32:58 +1300    

Click here for diff

While cleaning up after a parallel query or parallel index creation that  
created temporary files, we could be interrupted by a statement timeout.  
The error handling path would then fail to clean up the files when it  
ran dsm_detach() again, because the callback was already popped off the  
list.  Prevent this hazard by holding interrupts while the cleanup code  
runs.  
  
Thanks to Heikki Linnakangas for this suggestion, and also to Kyotaro  
Horiguchi, Masahiko Sawada, Justin Pryzby and Tom Lane for discussion of  
this and earlier ideas on how to fix the problem.  
  
Back-patch to all supported releases.  
  
Reported-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20191212180506.GR2082@telsasoft.com  

M src/backend/storage/ipc/dsm.c

pg_attribute_no_sanitize_alignment() macro

commit   : c3dc311ffd6417b15a467c6ea53e642577e9f00e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Feb 2021 17:49:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Feb 2021 17:49:08 -0500    

Click here for diff

Modern gcc and clang compilers offer alignment sanitizers, which help to detect  
pointer misalignment.  However, our codebase already contains x86-specific  
crc32 computation code, which uses unalignment access.  Thankfully, those  
compilers also support the attribute, which disables alignment sanitizers at  
the function level.  This commit adds pg_attribute_no_sanitize_alignment(),  
which wraps this attribute, and applies it to pg_comp_crc32c_sse42() function.  
  
Back-patch of commits 993bdb9f9 and ad2ad698a, to enable doing  
alignment testing in all supported branches.  
  
Discussion: https://postgr.es/m/CAPpHfdsne3%3DT%3DfMNU45PtxdhSL_J2PjLTeS8rwKnJzUR4YNd4w%40mail.gmail.com  
Discussion: https://postgr.es/m/475514.1612745257%40sss.pgh.pa.us  
Author: Alexander Korotkov, revised by Tom Lane  
Reviewed-by: Tom Lane  

M src/include/c.h
M src/port/pg_crc32c_sse42.c

Avoid divide-by-zero in regex_selectivity() with long fixed prefix.

commit   : 0347470b31c139aa4f1d366fbdb85f32b7f82ad0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Feb 2021 16:26:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Feb 2021 16:26:47 -0500    

Click here for diff

Given a regex pattern with a very long fixed prefix (approaching 500  
characters), the result of pow(FIXED_CHAR_SEL, fixed_prefix_len) can  
underflow to zero.  Typically the preceding selectivity calculation  
would have underflowed as well, so that we compute 0/0 and get NaN.  
In released branches this leads to an assertion failure later on.  
That doesn't happen in HEAD, for reasons I've not explored yet,  
but it's surely still a bug.  
  
To fix, just skip the division when the pow() result is zero, so  
that we'll (most likely) return a zero selectivity estimate.  In  
the edge cases where "sel" didn't yet underflow, perhaps this  
isn't desirable, but I'm not sure that the case is worth spending  
a lot of effort on.  The results of regex_selectivity_sub() are  
barely worth the electrons they're written on anyway :-(  
  
Per report from Alexander Lakhin.  Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/6de0a0c3-ada9-cd0c-3e4e-2fa9964b41e3@gmail.com  

M src/backend/utils/adt/like_support.c

Fix ORDER BY clause in new regression test of REINDEX CONCURRENTLY

commit   : 5b2945ec0a39959962072c39d1817d0fdf23d486    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Feb 2021 16:59:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Feb 2021 16:59:04 +0900    

Click here for diff

Oversight in bd12080.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20210210065805.GG20012@telsasoft.com  
Backpatch-through: 12  

M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql

Preserve pg_attribute.attstattarget across REINDEX CONCURRENTLY

commit   : 85edb1f2615d48bdc2420b00c55286eef3a3244c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Feb 2021 13:09:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Feb 2021 13:09:12 +0900    

Click here for diff

For an index, attstattarget can be updated using ALTER INDEX SET  
STATISTICS.  This data was lost on the new index after REINDEX  
CONCURRENTLY.  
  
The update of this field is done when the old and new indexes are  
swapped to make the fix back-patchable.  Another approach we could look  
after in the long-term is to change index_create() to pass the wanted  
values of attstattarget when creating the new relation, but, as this  
would cause an ABI breakage this can be done only on HEAD.  
  
Reported-by: Ronan Dunklau  
Author: Michael Paquier  
Reviewed-by: Ronan Dunklau, Tomas Vondra  
Discussion: https://postgr.es/m/16628084.uLZWGnKmhe@laptop-ronand  
Backpatch-through: 12  

M src/backend/catalog/index.c
M src/backend/utils/cache/lsyscache.c
M src/include/utils/lsyscache.h
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql