PostgreSQL 11.12 (upcoming) commit log

Clarify the usage of max_replication_slots on the subscriber side.

commit   : 25b13721d41de3d74771f02b9827aac66bc97d33    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Mar 2021 10:32:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Mar 2021 10:32:43 +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   : ae1c1d84ea2465a25bc2f20b9c22d0c5779c5b08    
  
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 use-after-free bug with AfterTriggersTableData.storeslot

commit   : d1c6edd31d6c3e6d173d47a64a3b28660705def7    
  
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/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql

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

commit   : de19e5e0ca2f8cbffef8bc8d40df509fc918f4f9    
  
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

Fix some typos, grammar and style in docs and comments

commit   : 70dc2385f9a20c8d397a244b5237831790d8e2a6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Feb 2021 16:14:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Feb 2021 16:14:03 +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   : 2583917075ae9fc40d29c679867367db68be004b    
  
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 another ancient bug in parsing of BRE-mode regular expressions.

commit   : 6e6fecf495386e8aebfdc71ad6998eceb9da45e3    
  
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   : 5d319ce86f13d1b0e7fb911408fe012723259723    
  
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   : 6e437ce5a6b64c443cf7c907db0988bf571e6042    
  
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

Default to wal_sync_method=fdatasync on FreeBSD.

commit   : 1fefe8879a684666fee8353bef99e8c3e6f15901    
  
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   : acafdd9ed5f05742730ee666abf49b89e8a125ad    
  
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   : 22001684623bd95b4e1d5c21854f222a37b13267    
  
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   : a28df6fa3041523f9a96cf0d3c3929f8bdc7c797    
  
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/selfuncs.c