PostgreSQL 10.9 commit log

commit   : cb4cb7401e12f5796a5e16fabddeffae3cac39b5    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2019 17:18:49 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2019 17:18:49 -0400    

commit   : 8339895d8f797d8d1ccbd555937ed8cc727ea279    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2019 10:53:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2019 10:53:45 -0400    

Security: CVE-2019-10164  

commit   : 435a2bf39e8e589524b38fa9400137ad9fec8c00    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2019 15:00:56 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2019 15:00:56 +0200    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 18b2987be55cfb9eaf7059e9d4e017642c40a2a8  

commit   : d72a7e4da1001b29a661a4b1a52cb5c4d708bab0    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 17 Jun 2019 22:14:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 17 Jun 2019 22:14:09 +0900    

When a client connects to a rogue server sending specifically-crafted  
messages, this can suffice to execute arbitrary code as the operating  
system account used by the client.  
  
While on it, fix one error handling when decoding an incorrect salt  
included in the first message received from server.  
  
Author: Michael Paquier  
Reviewed-by: Jonathan Katz, Heikki Linnakangas  
Security: CVE-2019-10164  
Backpatch-through: 10  

commit   : 90adc16ea13750a6b6f704c6cf65dc0f1bdb845c    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 17 Jun 2019 21:48:34 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 17 Jun 2019 21:48:34 +0900    

Any authenticated user can overflow a stack-based buffer by changing the  
user's own password to a purpose-crafted value.  This often suffices to  
execute arbitrary code as the PostgreSQL operating system account.  
  
This fix is contributed by multiple folks, based on an initial analysis  
from Tom Lane.  This issue has been introduced by 68e61ee, so it was  
possible to make use of it at authentication time.  It became more  
easily to trigger after ccae190 which has made the SCRAM parsing more  
strict when changing a password, in the case where the client passes  
down a verifier already hashed using SCRAM.  Back-patch to v10 where  
SCRAM has been introduced.  
  
Reported-by: Alexander Lakhin  
Author: Jonathan Katz, Heikki Linnakangas, Michael Paquier  
Security: CVE-2019-10164  
Backpatch-through: 10  

commit   : 93d4484ef80aa4df04f70348fd34d45d2eb85416    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sun, 16 Jun 2019 22:24:20 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sun, 16 Jun 2019 22:24:20 -0400    

This reverts commits 3da73d6839dc and de87a084c0a5.  
  
This code has some tricky corner cases that I'm not sure are correct and  
not properly tested anyway, so I'm reverting the whole thing for next  
week's releases (reintroducing the deadlock bug that we set to fix).  
I'll try again afterwards.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0e45e52b5165c403174e942a6c6f96cd99d6192c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 16 Jun 2019 15:39:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 16 Jun 2019 15:39:08 -0400    

(11.4 notes are already done.)  

commit   : 2913a892e1b21a4079f334c52c71704b828f73d8    
  
author   : Andrew Gierth <[email protected]>    
date     : Sat, 15 Jun 2019 18:15:23 +0100    
  
committer: Andrew Gierth <[email protected]>    
date     : Sat, 15 Jun 2019 18:15:23 +0100    

tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate  
zone with its own abbreviation. Unfortunately, our code for choosing a  
timezone in initdb has an arbitrary preference for names earlier in  
the alphabet, and so it would choose the spelling "UCT" over "UTC"  
when the system is running on a UTC zone.  
  
Commit 23bd3cec6 was backpatched in order to address this issue, but  
that code helps only when /etc/localtime exists as a symlink, and does  
nothing to help on systems where /etc/localtime is a copy of a zone  
file (as is the standard setup on FreeBSD and probably some other  
platforms too) or when /etc/localtime is simply absent (giving UTC as  
the default).  
  
Accordingly, add a preference for the spelling "UTC", such that if  
multiple zone names have equally good content matches, we prefer that  
name before applying the existing arbitrary rules. Also add a slightly  
lower preference for "Etc/UTC"; lower because that preserves the  
previous behaviour of choosing the shorter name, but letting us still  
choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does  
not (not common, but I've seen it happen).  
  
Backpatch all the way, because the tzdb change that sparked this issue  
is in those branches too.  

commit   : 744639739c7c6a53bcbf4cd6fe765d7ebd89716a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 14 Jun 2019 11:33:40 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 14 Jun 2019 11:33:40 -0400    

Introduced in de87a084c0a5.  

commit   : 8de574aa8bf7130f8291fc0be97e19a8074d2e05    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2019 11:25:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2019 11:25:13 -0400    

On many modern platforms, /etc/localtime is a symlink to a file within the  
IANA database.  Reading the symlink lets us find out the name of the system  
timezone directly, without going through the brute-force search embodied in  
scan_available_timezones().  This shortens the runtime of initdb by some  
tens of ms, which is helpful for the buildfarm, and it also allows us to  
reliably select the same zone name the system was actually configured for,  
rather than possibly choosing one of IANA's many zone aliases.  (For  
example, in a system configured for "Asia/Tokyo", the brute-force search  
would not choose that name but its alias "Japan", on the grounds of the  
latter string being shorter.  More surprisingly, "Navajo" is preferred  
to either "America/Denver" or "US/Mountain", as seen in an old complaint  
from Josh Berkus.)  
  
If /etc/localtime doesn't exist, or isn't a symlink, or we can't make  
sense of its contents, or the contents match a zone we know but that  
zone doesn't match the observed behavior of localtime(), fall back to  
the brute-force search.  
  
Also, tweak initdb so that it prints the zone name it selected.  
  
In passing, replace the last few references to the "Olson" database in  
code comments with "IANA", as that's been our preferred term since  
commit b2cbced9e.  
  
Back-patch of commit 23bd3cec6.  The original intention was to not  
back-patch, since this can result in cosmetic behavioral changes ---  
for example, on my own workstation initdb now chooses "America/New_York",  
where it used to prefer "US/Eastern" which is equivalent and shorter.  
However, our hand has been more or less forced by tzdb update 2019a,  
which made the "UCT" zone fully equivalent to "UTC".  Our old code  
now prefers "UCT" on the grounds of it being alphabetically first,  
and that's making nobody happy.  Choosing the alias indicated by  
/etc/localtime is a more defensible behavior.  (Users who don't like  
the results can always force the decision by setting the TZ environment  
variable before running initdb.)  
  
Patch by me, per a suggestion from Robert Haas; review by Michael Paquier  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 14a91a8fc279e9ea438f73049d93481d99b5b9f9    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 13 Jun 2019 17:28:24 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 13 Jun 2019 17:28:24 -0400    

When two (or more) transactions are waiting for transaction T1 to release a  
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a  
spurious deadlock can be reported among the waiting transactions when T1  
finishes.  The simplest example case seems to be:  
  
T1: select id from job where name = 'a' for key share;  
Y: select id from job where name = 'a' for update; -- starts waiting for X  
Z: select id from job where name = 'a' for key share;  
T1: update job set name = 'b' where id = 1;  
Z: update job set name = 'c' where id = 1; -- starts waiting for X  
T1: rollback;  
  
At this point, transaction Y is rolled back on account of a deadlock: Y  
holds the heavyweight tuple lock and is waiting for the Xmax to be released,  
while Z holds part of the multixact and tries to acquire the heavyweight  
lock (per protocol) and goes to sleep; once X releases its part of the  
multixact, Z is awakened only to be put back to sleep on the heavyweight  
lock that Y is holding while sleeping.  Kaboom.  
  
This can be avoided by having Z skip the heavyweight lock acquisition.  As  
far as I can see, the biggest downside is that if there are multiple Z  
transactions, the order in which they resume after X finishes is not  
guaranteed.  
  
Backpatch to 9.6.  The patch applies cleanly on 9.5, but the new tests don't  
work there (because isolationtester is not smart enough), so I'm not going  
to risk it.  
  
Author: Oleksii Kliukin  
Discussion: https://postgr.es/m/[email protected]  

commit   : 945ae92c8a5ef929778e2e25ebf4ee1909c54954    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2019 10:53:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2019 10:53:17 -0400    

Also MyReplicationSlot, in branches where it wasn't already.  
  
This was discussed in the thread that resulted in c572599c6, but  
for some reason nobody pulled the trigger.  Now that we have another  
request for the same thing, we should just do it.  
  
Craig Ringer  
  
Discussion: https://postgr.es/m/CAMsr+YFTsq-86MnsNng=mPvjjh5EAbzfMK0ptJPvzyvpFARuRg@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0f2b234263ef30b059c04dbebd22e166257159d4    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 13 Jun 2019 17:59:12 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 13 Jun 2019 17:59:12 +0900    

Previously, in postgresPlanForeignModify, we planned an UPDATE operation  
on a foreign table so that we transmit only columns that were explicitly  
targets of the UPDATE, so as to avoid unnecessary data transmission, but  
if there were BEFORE ROW UPDATE triggers on the foreign table, those  
triggers might change values for non-target columns, in which case we  
would miss sending changed values for those columns.  Prevent optimizing  
away transmitting all columns if there are BEFORE ROW UPDATE triggers on  
the foreign table.  
  
This is an oversight in commit 7cbe57c34 which added triggers on foreign  
tables, so apply the patch all the way back to 9.4 where that came in.  
  
Author: Shohei Mochizuki  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/[email protected]  

commit   : 909a92e1955256f41c411961e400a145d581ed2d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 22:54:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 22:54:46 -0400    

datatype.sgml failed to explain that boolin() accepts any unique  
prefix of the basic input strings.  Indeed it was actively misleading  
because it called out a few minimal prefixes without mentioning that  
there were more valid inputs.  
  
I also felt that it wasn't doing anybody any favors by conflating  
SQL key words, valid Boolean input, and string literals containing  
valid Boolean input.  Rewrite in hopes of reducing the confusion.  
  
Per bug #15836 from Yuming Wang, as diagnosed by David Johnston.  
Back-patch to supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 30d3df0a7b823d14c8bf43d949a122492b5d039c    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 19:42:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 19:42:39 -0400    

Given a query in which multiple JOIN nodes used the same alias  
(which'd necessarily be in different sub-SELECTs), ruleutils.c  
would assign the JOIN nodes distinct aliases for clarity ...  
but then it forgot to print the modified aliases when dumping  
the JOIN nodes themselves.  This results in a dump/reload hazard  
for views, because the emitted query is flat-out incorrect:  
Vars will be printed with table names that have no referent.  
  
This has been wrong for a long time, so back-patch to all supported  
branches.  
  
Philip Dubé  
  
Discussion: https://postgr.es/m/CY4PR2101MB080246F2955FF58A6ED1FEAC98140@CY4PR2101MB0802.namprd21.prod.outlook.com  

commit   : 1bbcbfaf7824590834df7352d3aaeb4ade43be31    
  
author   : David Rowley <[email protected]>    
date     : Thu, 13 Jun 2019 10:35:47 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 13 Jun 2019 10:35:47 +1200    

Reported-by: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqGZFkKi0TkBGYpr2_5qrRAbHZoP47AP1BRLUOUkfQdy_A@mail.gmail.com  
Backpatch-through: 10  

commit   : ac8f2e1ef34f6d9653825d75c0afa13604ed4e34    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 17:29:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 17:29:48 -0400    

This is quite unsafe, even for the case of ereport(FATAL) where we won't  
return control to the interrupted code, and despite this code's use of  
a flag to restrict the areas where we'd try to do it.  It's possible  
for example that we interrupt malloc or free while that's holding a lock  
that's meant to protect against cross-thread interference.  Then, any  
attempt to do malloc or free within ereport() will result in a deadlock,  
preventing the walreceiver process from exiting in response to SIGTERM.  
We hypothesize that this explains some hard-to-reproduce failures seen  
in the buildfarm.  
  
Hence, get rid of the immediate-exit code in WalRcvShutdownHandler,  
as well as the logic associated with WalRcvImmediateInterruptOK.  
Instead, we need to take care that potentially-blocking operations  
in the walreceiver's data transmission logic (libpqwalreceiver.c)  
will respond reasonably promptly to the process's latch becoming  
set and then call ProcessWalRcvInterrupts.  Much of the needed code  
for that was already present in libpqwalreceiver.c.  I refactored  
things a bit so that all the uses of PQgetResult use latch-aware  
waiting, but didn't need to do much more.  
  
These changes should be enough to ensure that libpqwalreceiver.c  
will respond promptly to SIGTERM whenever it's waiting to receive  
data.  In principle, it could block for a long time while waiting  
to send data too, and this patch does nothing to guard against that.  
I think that that hazard is mostly theoretical though: such blocking  
should occur only if we fill the kernel's data transmission buffers,  
and we don't generally send enough data to make that happen without  
waiting for input.  If we find out that the hazard isn't just  
theoretical, we could fix it by using PQsetnonblocking, but that  
would require more ticklish changes than I care to make now.  
  
Back-patch of commit a1a789eb5.  This problem goes all the way back  
to the origins of walreceiver; but given the substantial reworking  
the module received during the v10 cycle, it seems unsafe to assume  
that our testing on HEAD validates this patch for pre-v10 branches.  
And we'd need to back-patch some prerequisite patches (at least  
597a87ccc and its followups, maybe other things), increasing the risk  
of problems.  Given the dearth of field reports matching this problem,  
it's not worth much risk.  Hence back-patch to v10 and v11 only.  
  
Patch by me; thanks to Thomas Munro for review.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2981e5a6126c24037e5745a620e71266d53abbb3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 12:29:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 12:29:24 -0400    

ATExecAlterColumnType failed to consider the possibility that an index  
that needs to be rebuilt might be a child of a constraint that needs to be  
rebuilt.  We missed this so far because usually a constraint index doesn't  
have a direct dependency on its table, just on the constraint object.  
But if there's a WHERE clause, then dependency analysis of the WHERE  
clause results in direct dependencies on the column(s) mentioned in WHERE.  
This led to trying to drop and rebuild both the constraint and its  
underlying index.  
  
In v11/HEAD, we successfully drop both the index and the constraint,  
and then try to rebuild both, and of course the second rebuild hits a  
duplicate-index-name problem.  Before v11, it fails with obscure messages  
about a missing relation OID, due to trying to drop the index twice.  
  
This is essentially the same kind of problem noted in commit  
20bef2c31: the possible dependency linkages are broader than what  
ATExecAlterColumnType was designed for.  It was probably OK when  
written, but it's certainly been broken since the introduction of  
partial exclusion constraints.  Fix by adding an explicit check  
for whether any of the indexes-to-be-rebuilt belong to any of the  
constraints-to-be-rebuilt, and ignoring any that do.  
  
In passing, fix a latent bug introduced by commit 8b08f7d48: in  
get_constraint_index() we must "continue" not "break" when rejecting  
a relation of a wrong relkind.  This is harmless today because we don't  
expect that code path to be taken anyway; but if there ever were any  
relations to be ignored, the existing coding would have an extremely  
undesirable dependency on the order of pg_depend entries.  
  
Also adjust a couple of obsolete comments.  
  
Per bug #15835 from Yaroslav Schekin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 56a932533aa2de49d654ca401e6593b3228627ce    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 12 Jun 2019 11:31:00 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 12 Jun 2019 11:31:00 +0900    

For a non-superuser, changing a comment on a domain constraint was  
leading to a cache lookup failure as the code tried to perform the  
ownership lookup on the constraint OID itself, thinking that it was a  
type, but this check needs to happen on the type the domain constraint  
relies on.  As the type a domain constraint relies on can be guessed  
directly based on the constraint OID, first fetch its type OID and  
perform the ownership on it.  
  
This is broken since 7eca575, which has split the handling of comments  
for table constraints and domain constraints, so back-patch down to  
9.5.  
  
Reported-by: Clemens Ladisch  
Author: Daniel Gustafsson, Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.5  

commit   : 6e1dc84533e45242f2a0bae87f324fcb9bd5cd11    
  
author   : David Rowley <[email protected]>    
date     : Wed, 12 Jun 2019 08:09:28 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 12 Jun 2019 08:09:28 +1200    

A few questionable partitioning designs have been cropping up lately  
around the mailing lists.  Generally, these cases have been partitioning  
using too many partitions which have caused performance or OOM problems for  
the users.  
  
Since we have very little else to guide users into good design, here we  
add a new section to the partitioning documentation with some best  
practise guidelines for good design.  
  
Reviewed-by: Justin Pryzby, Amit Langote, Alvaro Herrera  
Discussion: https://postgr.es/m/CAKJS1f-2rx+E9mG3xrCVHupefMjAp1+tpczQa9SEOZWyU7fjEA@mail.gmail.com  
Backpatch-through: 10  

commit   : b6f5689aadf42b9afa3bf972d3deee839541a3ba    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Jun 2019 13:33:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Jun 2019 13:33:08 -0400    

json_to_record(), when an output column is declared as type json or jsonb,  
should emit the corresponding field of the input JSON object.  But it got  
this slightly wrong when the field is just a string literal: it failed to  
escape the contents of the string.  That typically resulted in syntax  
errors if the string contained any double quotes or backslashes.  
  
jsonb_to_record() handles such cases correctly, but I added corresponding  
test cases for it too, to prevent future backsliding.  
  
Improve the documentation, as it provided only a very hand-wavy  
description of the conversion rules used by these functions.  
  
Per bug report from Robert Vollmert.  Back-patch to v10 where the  
error was introduced (by commit cf35346e8).  
  
Note that PG 9.4 - 9.6 also get this case wrong, but differently so:  
they feed the de-escaped contents of the string literal to json[b]_in.  
That behavior is less obviously wrong, so possibly it's being depended on  
in the field, so I won't risk trying to make the older branches behave  
like the newer ones.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 52ad5fc0a6c353a72513cc3730d062a2de1d4952    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 10 Jun 2019 23:20:48 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 10 Jun 2019 23:20:48 -0700    

Vignesh found this bug in the check function for  
default_table_access_method's check hook, but that was just copied  
from older GUCs. Investigation by Michael and me then found the bug in  
further places.  
  
When not connected to a database (e.g. in a walsender connection), we  
cannot perform (most) GUC checks that need database access. Even when  
only shared tables are needed, unless they're  
nailed (c.f. RelationCacheInitializePhase2()), they cannot be accessed  
without pg_class etc. being present.  
  
Fix by extending the existing IsTransactionState() checks to also  
check for MyDatabaseOid.  
  
Reported-By: Vignesh C, Michael Paquier, Andres Freund  
Author: Vignesh C, Andres Freund  
Discussion: https://postgr.es/m/CALDaNm1KXK9gbZfY-p_peRFm_XrBh1OwQO1Kk6Gig0c0fVZ2uw%40mail.gmail.com  
Backpatch: 9.4-  

commit   : 1eb8a5ea463dcbe6546f684e862649fd4e643953    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 10 Jun 2019 18:56:23 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 10 Jun 2019 18:56:23 -0400    

Using PARTITION OF can result in column ordering being changed from the  
database being dumped, if the partition uses a column layout different  
from the parent's.  It's not pg_dump's job to editorialize on table  
definitions, so this is not acceptable; back-patch all the way back to  
pg10, where partitioned tables where introduced.  
  
This change also ensures that partitions end up in the correct  
tablespace, if different from the parent's; this is an oversight in  
ca4103025dfe (in pg12 only).  Partitioned indexes (in pg11) don't have  
this problem, because they're already created as independent indexes and  
attached to their parents afterwards.  
  
This change also has the advantage that the partition is restorable from  
the dump (as a standalone table) even if its parent table isn't  
restored.  
  
The original commits (3b23552ad8bb in branch master) failed to cover  
subsidiary column elements correctly, such as NOT NULL constraint and  
CHECK constraints, as reported by Rushabh Lathia (initially as a failure  
to restore serial columns).  They were reverted.  This recapitulation  
commit fixes those problems.  
  
Add some pg_dump tests to verify these things more exhaustively,  
including constraints with legacy-inheritance tables, which were not  
tested originally.  In branches 10 and 11, add a local constraint to the  
pg_dump test partition that was added by commit 2d7eeb1b1492 to master.  
  
Author: Álvaro Herrera, David Rowley  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAGPqQf0iQV=PPOv2Btog9J9AwOQp6HmuVd6SbGTR_v3Zp2XT1w@mail.gmail.com  

commit   : 589f91fc312e79caf95e0ce44452ab2e7d57728e    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 10 Jun 2019 20:14:19 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Mon, 10 Jun 2019 20:14:19 +0300    

Descriptions of pg_trgm GUC options have % replaced with %% like it was  
a printf-like format.  But that's not needed since they are just plain strings.  
This commit fixed that.  Backpatch to last supported version since this error  
present from the beginning.  
  
Reported-by: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoAgPKODUsu9gqUFiNqEOAqedStxJ-a0sapsJXWWAVp%3Dxg%40mail.gmail.com  
Backpatch-through: 9.4  

commit   : 9ee98cc3fae297d4468fd970f3d9aa16794210f5    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 10 Jun 2019 19:38:13 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Mon, 10 Jun 2019 19:38:13 +0300    

be8a7a68 introduced pg_trgm.strict_word_similarity_threshold GUC, but missed  
docs for that.  This commit fixes that.  
  
Discussion: https://postgr.es/m/fc907f70-448e-fda3-3aa4-209a59597af0%402ndquadrant.com  
Author: Ian Barwick  
Reviewed-by: Masahiko Sawada, Michael Paquier  
Backpatch-through: 9.6  

commit   : 7c2122f11f0fbc740dd08c0bea3ff1dbf07d4007    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 10 Jun 2019 19:28:47 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Mon, 10 Jun 2019 19:28:47 +0300    

5871b884 introduced pg_trgm.word_similarity_threshold GUC, but its documentation  
contains wrong indentation.  This commit fixes that.  Backpatch for easier  
backpatching of other documentation fixes.  
  
Discussion: https://postgr.es/m/4c735d30-ab59-fc0e-45d8-f90eb5ed3855%402ndquadrant.com  
Author: Ian Barwick  
Backpatch-through: 9.6  

commit   : 88ca787b16cc5eee79e2e543b2da74ea5b872a85    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 7 Jun 2019 12:44:01 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 7 Jun 2019 12:44:01 +0300    

It's harmless to call PQfreemem() with a NULL argument, so the only  
consequence was that if allocating 'schema' failed, but allocating 'table'  
or 'field' succeeded, we would leak a bit of memory. That's highly  
unlikely to happen, so this is just academical, but let's get it right.  
  
Per bug #15838 from Timur Birsh. Backpatch back to 9.5, where the  
PQfreemem() calls were introduced.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : fac1ed2742938080112e5e394fb281f7ca361d59    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 7 Jun 2019 05:35:31 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 7 Jun 2019 05:35:31 +0530    

When this code was initially introduced in commit d1b7c1ff, the structure  
used was SharedPlanStateInstrumentation, but later when it got changed to  
Instrumentation structure in commit b287df70, we forgot to update the  
comment.  
  
Reported-by: Wu Fei  
Author: Wu Fei  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/52E6E0843B9D774C8C73D6CF64402F0562215EB2@G08CNEXMBPEKD02.g08.fujitsu.local  

commit   : 974a2867ea5da8d5a8cc31bb9c8897e118fb1a89    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Jun 2019 21:25:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Jun 2019 21:25:43 -0400    

Back-patch commit 09a65f5a2 into the 9.6 and 10 branches.  
Needed to support back-patch of commit 2cd4e8357 on Windows.  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : ba38967d7567342bb547d8aafa8e9bab24396df4    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Jun 2019 18:06:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Jun 2019 18:06:04 -0400    

A parallel worker process should not be making any decisions of its  
own about whether to auto-explain.  If the parent session process  
passed down flags asking for instrumentation data, do that, otherwise  
not.  Trying to enable instrumentation anyway leads to bugs like the  
"could not find key N in shm TOC" failure reported in bug #15821  
from Christian Hofstaedtler.  
  
We can implement this cheaply by piggybacking on the existing logic  
for not doing anything when we've chosen not to sample a statement.  
  
While at it, clean up some tin-eared coding related to the sampling  
feature, including an off-by-one error that meant that asking for 1.0  
sampling rate didn't actually result in sampling every statement.  
  
Although the specific case reported here only manifested in >= v11,  
I believe that related misbehaviors can be demonstrated in any version  
that has parallel query; and the off-by-one error is certainly there  
back to 9.6 where that feature was added.  So back-patch to 9.6.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5b8c93c8742a3779e59759f8e482428246e8547c    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 1 Jun 2019 15:34:02 -0400    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 1 Jun 2019 15:34:02 -0400    

Support of CHECK OPTION for updatable views has been added in 9.4, but  
the documentation of information_schema never got the call even if the  
information displayed is correct.  
  
Author: Gilles Darold  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : 683c17b3071f4ad7c78f106f25118fc07b350be9    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 31 May 2019 12:34:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 31 May 2019 12:34:54 -0400    

Rename some exposed parameters so that they don't conflict with  
C++ reserved words.  
  
Back-patch to all supported versions.  
  
George Tarasov  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 39c9efc15646b3eb36d4095c3657405894dc3ea4    
  
author   : Tomas Vondra <[email protected]>    
date     : Thu, 30 May 2019 16:16:12 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Thu, 30 May 2019 16:16:12 +0200    

Most errors reported in extended statistics are internal issues, and so  
should use elog(). The MCV list code was already following this rule, but  
the functional dependencies and ndistinct coefficients were using a mix  
of elog() and ereport(). Fix this by changing most places to elog(), with  
the exception of input functions.  
  
This is a mostly cosmetic change, it makes the life a little bit easier  
for translators, as elog() messages are not translated. So backpatch to  
PostgreSQL 10, where extended statistics were introduced.  
  
Author: Tomas Vondra  
Backpatch-through: 10 where extended statistics were added  
Discussion: https://postgr.es/m/[email protected]  

commit   : b31d88b010b44e3c0c1a7b62966f91a55d5d9b8d    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 28 May 2019 19:28:36 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 28 May 2019 19:28:36 -0700    

My back-patch of commit 10b72deafea5972edcafb9eb3f97154f32ccd340 added  
calls to File::Path::rmtree(), but v10 and older had not been importing  
that symbol.  Back-patch to v10, 9.6 and 9.5.  

commit   : c44e9bc3a10f8c6dff07db355375339d7a6db24b    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 28 May 2019 12:59:00 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 28 May 2019 12:59:00 -0700    

When this suite runs installcheck, redirect file creations from  
src/test/regress to src/bin/pg_upgrade/tmp_check/regress.  This closes a  
race condition in "make -j check-world".  If the pg_upgrade suite wrote  
to a given src/test/regress/results file in parallel with the regular  
src/test/regress invocation writing it, a test failed spuriously.  Even  
without parallelism, in "make -k check-world", the suite finishing  
second overwrote the other's regression.diffs.  This revealed test  
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.  
  
Buildfarm client REL_10, released fifty-four days ago, supports saving  
regression.diffs from its new location.  When an older client reports a  
pg_upgradeCheck failure, it will no longer include regression.diffs.  
Back-patch to 9.5, where pg_upgrade moved to src/bin.  
  
Reviewed (in earlier versions) by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8e2b41ecf8acaf36208fafec4a01ffad04fb69a2    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 28 May 2019 12:58:30 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 28 May 2019 12:58:30 -0700    

This allows "vcregress upgradecheck" to pass twice in immediate  
succession, and it's more like how $(prove_check) works.  Back-patch to  
9.5, where pg_upgrade moved to src/bin.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9ba3915ab6d27c555a80a6e2212cafb804372cb5    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 23 May 2019 14:46:57 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 23 May 2019 14:46:57 -0700    

On master (after 700538) the old version's installed psql was used -  
even when the old version might not actually be installed / might be  
installed into a temporary directory. As commonly the case when just  
executing make check for pg_upgrade, as $oldbindir is just the current  
version's $bindir.  
  
In the back branches, with --install specified, psql from the new  
version's temporary installation was used, without --install (e.g for  
NO_TEMP_INSTALL, cf 47b3c26642), the new version's installed psql was  
used (which might or might not exist).  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  

commit   : 99efd8d727b0662e152daa2ccd1dcc668ac36056    
  
author   : Andrew Gierth <[email protected]>    
date     : Thu, 23 May 2019 15:26:01 +0100    
  
committer: Andrew Gierth <[email protected]>    
date     : Thu, 23 May 2019 15:26:01 +0100    

When there were duplicate columns in the hash key list, the array  
sizes could be miscomputed, resulting in access off the end of the  
array. Adjust the computation to ensure the array is always large  
enough.  
  
(I considered whether the duplicates could be removed in planning, but  
I can't rule out the possibility that duplicate columns might have  
different hash functions assigned. Simpler to just make sure it works  
at execution time regardless.)  
  
Bug apparently introduced in fc4b3dea2 as part of narrowing down the  
tuples stored in the hashtable. Reported by Colm McHugh of Salesforce,  
though I didn't use their patch. Backpatch back to version 10 where  
the bug was introduced.  
  
Discussion: https://postgr.es/m/CAFeeJoKKu0u+A_A9R9316djW-YW3-+Gtgvy3ju655qRHR3jtdA@mail.gmail.com  

commit   : 2ccebcd23689779b97db1375d038b50bed8dcd68    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 23 May 2019 10:48:29 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 23 May 2019 10:48:29 +0900    

This uses a method similar to 68a7c24f and now b8c6014 (applied for  
database creation), which guarantees that GRANT commands using the WITH  
GRANT OPTION are dumped in a way so as cascading dependencies are  
respected.  Note that tablespaces do not have support for initial  
privileges via pg_init_privs, so the same method needs to be applied  
again.  It would be nice to merge all the logic generating ACL queries  
in dumps under the same banner, but this requires extending the support  
of pg_init_privs to objects that cannot use it yet, so this is left as  
future work.  
  
Discussion: https://postgr.es/m/[email protected]  
Author: Michael Paquier  
Reviewed-by: Nathan Bossart  
Backpatch-through: 9.6  

commit   : 0c2a5a86263c07ed1ae7a2fa032e0412961e412e    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 22 May 2019 14:48:30 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 22 May 2019 14:48:30 +0900    

This uses a method similar to 68a7c24f, which guarantees that GRANT  
commands using the WITH GRANT OPTION are dumped in a way so as cascading  
dependencies are respected.  As databases do not have support for  
initial privileges via pg_init_privs, we need to repeat again the same  
ACL reordering method.  
  
ACL for databases have been moved from pg_dumpall to pg_dump in v11, so  
this impacts pg_dump for v11 and above, and pg_dumpall for v9.6 and  
v10.  
  
Discussion: https://postgr.es/m/[email protected]  
Author: Nathan Bossart  
Reviewed-by: Haribabu Kommi  
Backpatch-through: 9.6  

commit   : 7f920b8f71aa2083ca6eaf0f254e3a68be3f208d    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 20 May 2019 09:48:37 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 20 May 2019 09:48:37 +0900    

Discussion: https://postgr.es/m/[email protected]  
Author: Liudmila Mantrova  
Reviewed-by: Jonathan Katz, Tom Lane, Michael Paquier  
Backpatch-through: 9.4  

commit   : e0a39a1d9a15da5c9a4bdb7d2599ad8499a02b39    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 19 May 2019 15:24:42 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 19 May 2019 15:24:42 -0700    

This reverts commit bd1592e8570282b1650af6b8eede0016496daecd.  It had  
multiple defects.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 422584caf32fa0477272447fd3f3851211310a6e    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 19 May 2019 14:36:44 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 19 May 2019 14:36:44 -0700    

When this suite runs installcheck, redirect file creations from  
src/test/regress to src/bin/pg_upgrade/tmp_check/regress.  This closes a  
race condition in "make -j check-world".  If the pg_upgrade suite wrote  
to a given src/test/regress/results file in parallel with the regular  
src/test/regress invocation writing it, a test failed spuriously.  Even  
without parallelism, in "make -k check-world", the suite finishing  
second overwrote the other's regression.diffs.  This revealed test  
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.  
  
Buildfarm client REL_10, released forty-five days ago, supports saving  
regression.diffs from its new location.  When an older client reports a  
pg_upgradeCheck failure, it will no longer include regression.diffs.  
Back-patch to 9.5, where pg_upgrade moved to src/bin.  
  
Reviewed by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 04595960a0a7c8844198668186bec2a6115244e0    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 14 May 2019 11:45:40 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 14 May 2019 11:45:40 -0700    

This path previously was not reliably covered. There was some  
heuristic coverage via insert-conflict-toast.spec, but that test is  
not deterministic, and only tested for a somewhat specific bug.  
  
Backpatch, as this is a complicated and otherwise untested code  
path. Unfortunately 9.5 cannot handle two waiting sessions, and thus  
cannot execute this test.  
  
Triggered by a conversion with Melanie Plageman.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/CAAKRu_a7hbyrk=wveHYhr4LbcRnRCG=yPUVoQYB9YO1CdUBE9Q@mail.gmail.com  
Backpatch: 9.5-  

commit   : d7bf9ad8431700763a135710e2685317c67e25bc    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 14 May 2019 13:09:28 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 14 May 2019 13:09:28 +0300    

The conditions listed in this comment have changed several times, and at  
some point the thing that the "if so" referred to was negated.  
  
The text was OK up to 9.6. It was differently wrong in v10, v11 and  
master, so fix in all those versions.  

commit   : 0569f047e8d65f1ed08280bc9ad535cfbbe0829a    
  
author   : Peter Geoghegan <[email protected]>    
date     : Mon, 13 May 2019 15:39:03 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Mon, 13 May 2019 15:39:03 -0700    

An upcoming HEAD-only patch will standardize the terminology around  
ItemIdData variables/line pointers, ending the practice of referring to  
them as "item pointers".  Make the "Database Page Layout" docs  
consistent with the new policy.  The term "item identifier" is already  
used in the same section, so stick with that.  
  
Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=E4ndQ2--8ew@mail.gmail.com  
Backpatch: All supported branches.  

commit   : 3b505036a129af5bbbf40a00f8997fc15438bb38    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 May 2019 17:23:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 May 2019 17:23:00 -0400    

Only hand-assigned type OIDs should be presumed to match across different  
PG servers; those assigned during genbki.pl or during initdb are likely  
to change due to addition or removal of unrelated objects.  
  
This means that the cutoff should be FirstGenbkiObjectId (in HEAD)  
or FirstBootstrapObjectId (before that), not FirstNormalObjectId.  
Compare postgres_fdw's is_builtin() test.  
  
It's likely that this error has no observable consequence in a  
normally-functioning system, since ATM the only affected type OIDs are  
system catalog rowtypes and information_schema types, which would not  
typically be interesting for logical replication.  But you could  
probably break it if you tried hard, so back-patch.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e3bf3c0f8c9c880ba808bc11c2825ecba720e4ed    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 May 2019 10:53:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 May 2019 10:53:19 -0400    

pgtls_read_pending is declared to return bool, but what the underlying  
SSL_pending function returns is a count of available bytes.  
  
This is actually somewhat harmless if we're using C99 bools, but in  
the back branches it's a live bug: if the available-bytes count happened  
to be a multiple of 256, it would get converted to a zero char value.  
On machines where char is signed, counts of 128 and up could misbehave  
as well.  The net effect is that when using SSL, libpq might block  
waiting for data even though some has already been received.  
  
Broken by careless refactoring in commit 4e86f1b16, so back-patch  
to 9.5 where that came in.  
  
Per bug #15802 from David Binderman.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7c16a2bfdcd8d477c8ff39c5eeb7d3b87fe0d60b    
  
author   : Etsuro Fujita <[email protected]>    
date     : Mon, 13 May 2019 17:30:38 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Mon, 13 May 2019 17:30:38 +0900    

commit   : 940f6479257d5ad297d08d9a205d057b108dca92    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 12 May 2019 18:53:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 12 May 2019 18:53:13 -0400    

A bounded quantifier with m = n = 1 might be thought a no-op.  But  
according to our documentation (which traces back to Henry Spencer's  
original man page) it still imposes greediness, or non-greediness in the  
case of the non-greedy variant "{1,1}?", on whatever it's attached to.  
  
This turns out not to work though, because parseqatom() optimizes away  
the m = n = 1 case without regard for whether it's supposed to change  
the greediness of the argument RE.  
  
We can fix this by just not applying the optimization when the greediness  
needs to change; the subsequent general cases handle it fine.  
  
The three cases in which we can still apply the optimization are  
(a) no quantifier, or quantifier does not impose a preference;  
(b) atom has no greediness property, implying it cannot match a  
variable amount of text anyway; or  
(c) quantifier's greediness is same as atom's.  
Note that in most cases where one of these applies, we'd have exited  
earlier in the "not a messy case" fast path.  I think it's now only  
possible to get to the optimization when the atom involves capturing  
parentheses or a non-top-level backref.  
  
Back-patch to all supported branches.  I'd ordinarily be hesitant to  
put a subtle behavioral change into back branches, but in this case  
it's very hard to see a reason why somebody would write "{1,1}?" unless  
they're trying to get the documented change-of-greediness behavior.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 409f5303ced62246d36cabb8d4c5da5f7ce7f376    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 12 May 2019 10:33:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 12 May 2019 10:33:05 -0700    

The function had been interpreting SQL_ASCII messages as UTF8, throwing  
an error when they were invalid UTF8.  The new behavior is consistent  
with pg_do_encoding_conversion().  This affects LOG_DESTINATION_STDERR  
and LOG_DESTINATION_EVENTLOG, which will send untranslated bytes to  
write() and ReportEventA().  On buildfarm member bowerbird, enabling  
log_connections caused an error whenever the role name was not valid  
UTF8.  Back-patch to 9.4 (all supported versions).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c3d113136bbaa86fbf1edde7aaf70ba06a6166b7    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 11 May 2019 21:27:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 11 May 2019 21:27:13 -0400    

We long ago decided to design the shared PgBackendStatus data structure to  
minimize the cost of writing status updates, which means that writers just  
have to increment the st_changecount field twice.  That isn't hooked into  
any sort of resource management mechanism, which means that if something  
were to throw error between the two increments, the st_changecount field  
would be left odd indefinitely.  That would cause readers to lock up.  
Now, since it's also a bad idea to leave the field odd for longer than  
absolutely necessary (because readers will spin while we have it set),  
the expectation was that we'd treat these segments like spinlock critical  
sections, with only short, more or less straight-line, code in them.  
  
That was fine as originally designed, but commit 9029f4b37 broke it  
by inserting a significant amount of non-straight-line code into  
pgstat_bestart(), code that is very capable of throwing errors, not to  
mention taking a significant amount of time during which readers will spin.  
We have a report from Neeraj Kumar of readers actually locking up, which  
I suspect was due to an encoding conversion error in X509_NAME_to_cstring,  
though conceivably it was just a garden-variety OOM failure.  
  
Subsequent commits have loaded even more dubious code into pgstat_bestart's  
critical section (and commit fc70a4b0d deserves some kind of booby prize  
for managing to miss the critical section entirely, although the negative  
consequences seem minimal given that the PgBackendStatus entry should be  
seen by readers as inactive at that point).  
  
The right way to fix this mess seems to be to compute all these values  
into a local copy of the process' PgBackendStatus struct, and then just  
copy the data back within the critical section proper.  This plan can't  
be implemented completely cleanly because of the struct's heavy reliance  
on out-of-line strings, which we must initialize separately within the  
critical section.  But still, the critical section is far smaller and  
safer than it was before.  
  
In hopes of forestalling future errors of the same ilk, rename the  
macros for st_changecount management to make it more apparent that  
the writer-side macros create a critical section.  And to prevent  
the worst consequences if we nonetheless manage to mess it up anyway,  
adjust those macros so that they really are a critical section, ie  
they now bump CritSectionCount.  That doesn't add much overhead, and  
it guarantees that if we do somehow throw an error while the counter  
is odd, it will lead to PANIC and a database restart to reset shared  
memory.  
  
Back-patch to 9.5 where the problem was introduced.  
  
In HEAD, also fix an oversight in commit b0b39f72b: it failed to teach  
pgstat_read_current_status to copy st_gssstatus data from shared memory to  
local memory.  Hence, subsequent use of that data within the transaction  
would potentially see changing data that it shouldn't see.  
  
Discussion: https://postgr.es/m/CAPR3Wj5Z17=+eeyrn_ZDG3NQGYgMEOY6JV6Y-WRRhGgwc16U3Q@mail.gmail.com  

commit   : 7a6a541234fdd929bc4a0f39538a4f05b69bc839    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 11 May 2019 00:22:38 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 11 May 2019 00:22:38 -0700    

The buildfarm client uses TEMP_CONFIG to implement its extra_config  
setting.  Except for stats_temp_directory, extra_config now applies to  
TAP suites; extra_config values seen in the past month are compatible  
with this.  Back-patch to 9.6, where PostgresNode was introduced, so the  
buildfarm can rely on it sooner.  
  
Reviewed by Andrew Dunstan and Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c6354e94304ca64815683042c5c6aa524f27c9f3    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 11 May 2019 13:01:12 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 11 May 2019 13:01:12 +0900    

When failing to reindex a table or an index, reindexdb would generate an  
extra error message related to a database failure, which is misleading.  
  
Backpatch all the way down, as this has been introduced by 85e9a5a0.  
  
Discussion: https://postgr.es/m/CAOBaU_Yo61RwNO3cW6WVYWwH7EYMPuexhKqufb2nFGOdunbcHw@mail.gmail.com  
Author: Julien Rouhaud  
Reviewed-by: Daniel Gustafsson, Álvaro Herrera, Tom Lane, Michael  
Paquier  
Backpatch-through: 9.4  

commit   : 3dcf45af560eeeef8d4ed4255a8d13ef16764dc4    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 May 2019 14:56:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 May 2019 14:56:41 -0400    

There's a very old race condition in our code to see whether a pre-existing  
shared memory segment is still in use by a conflicting postmaster: it's  
possible for the other postmaster to remove the segment in between our  
shmctl() and shmat() calls.  It's a narrow window, and there's no risk  
unless both postmasters are using the same port number, but that's possible  
during parallelized "make check" tests.  (Note that while the TAP tests  
take some pains to choose a randomized port number, pg_regress doesn't.)  
If it does happen, we treated that as an unexpected case and errored out.  
  
To fix, allow EINVAL to be treated as segment-not-present, and the same  
for EIDRM on Linux.  AFAICS, the considerations here are basically  
identical to the checks for acceptable shmctl() failures, so I documented  
and coded it that way.  
  
While at it, adjust PGSharedMemoryAttach's API to remove its undocumented  
dependency on UsedShmemSegAddr in favor of passing the attach address  
explicitly.  This makes it easier to be sure we're using a null shmaddr  
when probing for segment conflicts (thus avoiding questions about what  
EINVAL means).  I don't think there was a bug there, but it required  
fragile assumptions about the state of UsedShmemSegAddr during  
PGSharedMemoryIsInUse.  
  
Commit c09850992 may have made this failure more probable by applying  
the conflicting-segment tests more often.  Hence, back-patch to all  
supported branches, as that was.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 946cdf9ff771807885f49913b789fdc282b751bc    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 9 May 2019 16:52:49 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 9 May 2019 16:52:49 -0400    

create_merge_append_plan failed to honor the CP_EXACT_TLIST flag:  
it would generate the expected targetlist but then it felt free to  
add resjunk sort targets to it.  This demonstrably leads to assertion  
failures in v11 and HEAD, and it's probably just accidental that we  
don't see the same in older branches.  I've not looked into whether  
there would be any real-world consequences in non-assert builds.  
In HEAD, create_append_plan has sprouted the same problem, so fix  
that too (although we do not have any test cases that seem able to  
reach that bug).  This is an oversight in commit 3fc6e2d7f which  
invented the CP_EXACT_TLIST flag, so back-patch to 9.6 where that  
came in.  
  
convert_subquery_pathkeys would create pathkeys for subquery output  
values if they match any EquivalenceClass known in the outer query  
and are available in the subquery's syntactic targetlist.  However,  
the second part of that condition is wrong, because such values might  
not appear in the subquery relation's reltarget list, which would  
mean that they couldn't be accessed above the level of the subquery  
scan.  We must check that they appear in the reltarget list, instead.  
This can lead to dropping knowledge about the subquery's sort  
ordering, but I believe it's okay, because any sort key that the  
outer query actually has any interest in would appear in the  
reltarget list.  
  
This second issue is of very long standing, but right now there's no  
evidence that it causes observable problems before 9.6, so I refrained  
from back-patching further than that.  We can revisit that choice if  
somebody finds a way to make it cause problems in older branches.  
(Developing useful test cases for these issues is really problematic;  
fixing convert_subquery_pathkeys removes the only known way to exhibit  
the create_merge_append_plan bug, and neither of the test cases added  
by this patch causes a problem in all branches, even when considering  
the issues separately.)  
  
The second issue explains bug #15795 from Suresh Kumar R ("could not  
find pathkey item to sort" with nested DISTINCT queries).  I stumbled  
across the first issue while investigating that.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : db8802a99ed75e1f8f5ffab199cea7fb6f63a057    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 9 May 2019 10:29:40 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 9 May 2019 10:29:40 +0900    

When running a batch of VACUUM or ANALYZE commands on a given database,  
there were cases where it is possible to have vacuumdb not report an  
error where it actually should, leading to incorrect status results.  
  
Author: Julien Rouhaud  
Reviewed-by: Amit Kapila, Michael Paquier  
Discussion: https://postgr.es/m/CAOBaU_ZuTwz7CtqLYJ1Ouuh272bTQPLN8b1bAPk0bCBm4PDMTQ@mail.gmail.com  
Backpatch-through: 9.5  

commit   : 704637d8d935bee52f748641a0620e2e83de07d2    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 9 May 2019 01:35:13 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 9 May 2019 01:35:13 +0900    

Previously it's documented that use of replication functions is  
restricted to superusers. This is true for the functions which  
use replication origin, but not for pg_logicl_emit_message() and  
functions which use replication slot. For example, not only  
superusers but also users with REPLICATION privilege is allowed  
to use the functions for replication slot. This commit fixes  
the documentation for the privileges required for those replication  
functions.  
  
Back-patch to 9.4 (all supported versions).  
  
Author: Matsumura Ryo  
Discussion: https://postgr.es/m/03040DFF97E6E54E88D3BFEE5F5480F74ABA6E16@G01JPEXMBYT04  

commit   : 8c7a8e19bb17e0634e21ee8edbb912dc4deb5cb0    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 6 May 2019 15:02:41 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 6 May 2019 15:02:41 +1200    

Commit c0985099, later adjusted by commit 4ab02e81, probed 0.0.0.0  
in addition to 127.0.0.1, for the benefit of Windows build farm  
animals.  It isn't really useful on Unix systems, and turned out to  
be a bit inconvenient to users of some corporate firewall software.  
Switch back to probing just 127.0.0.1 on non-Windows systems.  
  
Back-patch to 9.6, like the earlier changes.  
  
Discussion: https://postgr.es/m/CA%2BhUKG%2B21EPwfgs4m%2BtqyRtbVqkOUvP8QQ8sWk9%2Bh55Aub1H3A%40mail.gmail.com  

commit   : 9e078fed21a0d60166896ffc82b5ff4c30b118d2    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 8 May 2019 09:32:34 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 8 May 2019 09:32:34 +0300    

The flat file mechanism was removed in PostgreSQL 9.0.  

commit   : 6bd3203b9e54a39805b531c3ce7e44e444c98541    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 7 May 2019 14:20:01 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 7 May 2019 14:20:01 +0900    

This code was broken as of 582edc3, and is most likely not used anymore.  
Note that pg_dump supports servers down to 8.0, and psql has code to  
support servers down to 7.4.  
  
Author: Julien Rouhaud  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAOBaU_Y5y=zo3+2gf+2NJC1pvMYPcbRXoQaPXx=U7+C8Qh4CzQ@mail.gmail.com