PostgreSQL 9.6.23 commit log

commit   : b979c788a9b79b615457e94b6e9f709513fe2e27    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Aug 2021 16:56:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Aug 2021 16:56:33 -0400    

commit   : eb8423e63b22421fb028cf0461c1298824d1cd98    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 9 Aug 2021 12:59:39 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 9 Aug 2021 12:59:39 +0200    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: fa603e561c327a9e166d1f2af227be6f187ea435  

commit   : 44ca43e36c54d30ed789d7e0544efeb5a5eb6c3b    
  
author   : David Rowley <[email protected]>    
date     : Mon, 9 Aug 2021 16:49:44 +1200    
  
committer: David Rowley <[email protected]>    
date     : Mon, 9 Aug 2021 16:49:44 +1200    

In ec34040af I added a mention that there was no point in setting  
maintenance_work_limit to anything higher than 1GB for vacuum, but that  
was incorrect as ginInsertCleanup() also looks at what  
maintenance_work_mem is set to during VACUUM and that's not limited to  
1GB.  
  
Here I attempt to make it more clear that the limitation is only around  
the number of dead tuple identifiers that we can collect during VACUUM.  
  
I've also added a note to autovacuum_work_mem to mention this limitation.  
I didn't do that in ec34040af as I'd had some wrong-headed ideas about  
just limiting the maximum value for that GUC to 1GB.  
  
Author: David Rowley  
Discussion: https://postgr.es/m/CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com  
Backpatch-through: 9.6, same as ec34040af  

commit   : c3c1fe09e7c34e1abbb0d30e69b7a26abe4d1411    
  
author   : Bruce Momjian <[email protected]>    
date     : Sun, 8 Aug 2021 21:05:46 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sun, 8 Aug 2021 21:05:46 -0400    

Since commit e462856a7a, pg_upgrade automatically creates a script to  
update extensions, so mention that instead of ALTER EXTENSION.  
  
Backpatch-through: 9.6  

commit   : d8650419bfbf10ae70bd24cafeadf58e107add76    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 8 Aug 2021 15:35:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 8 Aug 2021 15:35:31 -0400    

Copy-and-pasteo in 665c5855e, evidently.  The 9.6 docs toolchain  
whined about duplicate index entries, though our modern toolchain  
doesn't.  In any case, these GUCs surely are not about the  
default settings of these values.  

commit   : d5904d65080d3fd2c35b6aa74fa6c5762e32f87b    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 8 Aug 2021 14:35:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 8 Aug 2021 14:35:20 -0400    

commit   : c08b3a9eb6cc1b76be250d5a733a49cfc577fe99    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 7 Aug 2021 13:29:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 7 Aug 2021 13:29:32 -0400    

Rather than trying to pick table aliases that won't conflict with  
any possible user-defined matview column name, adjust the queries'  
syntax so that the aliases are only used in places where they can't be  
mistaken for column names.  Mostly this consists of writing "alias.*"  
not just "alias", which adds clarity for humans as well as machines.  
We do have the issue that "SELECT alias.*" acts differently from  
"SELECT alias", but we can use the same hack ruleutils.c uses for  
whole-row variables in SELECT lists: write "alias.*::compositetype".  
  
We might as well revert to the original aliases after doing this;  
they're a bit easier to read.  
  
Like 75d66d10e, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5b7b92ad74f2eeb4ac166bb45be31df95e574b3b    
  
author   : Dean Rasheed <[email protected]>    
date     : Fri, 6 Aug 2021 21:34:04 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Fri, 6 Aug 2021 21:34:04 +0100    

Formerly, the numeric code tested whether an integer value of a larger  
type would fit in a smaller type by casting it to the smaller type and  
then testing if the reverse conversion produced the original value.  
That's perfectly fine, except that it caused a test failure on  
buildfarm animal castoroides, most likely due to a compiler bug.  
  
Instead, do these tests by comparing against PG_INT16/32_MIN/MAX. That  
matches existing code in other places, such as int84(), which is more  
widely tested, and so is less likely to go wrong.  
  
While at it, add regression tests covering the numeric-to-int8/4/2  
conversions, and adjust the recently added tests to the style of  
434ddfb79a (on the v11 branch) to make failures easier to diagnose.  
  
Per buildfarm via Tom Lane, reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/2394813.1628179479%40sss.pgh.pa.us  

commit   : bf224e0a420397d9fdf8ead99a936fd44350f6bf    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 6 Aug 2021 20:55:59 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 6 Aug 2021 20:55:59 +0200    

commit   : ed3e1663c031e82def8c50ef31ee704777059459    
  
author   : Dean Rasheed <[email protected]>    
date     : Thu, 5 Aug 2021 09:35:46 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Thu, 5 Aug 2021 09:35:46 +0100    

This fixes a long-standing bug when using to_char() to format a  
numeric value in scientific notation -- if the value's exponent is  
less than -NUMERIC_MAX_DISPLAY_SCALE-1 (-1001), it produced a  
division-by-zero error.  
  
The reason for this error was that get_str_from_var_sci() divides its  
input by 10^exp, which it produced using power_var_int(). However, the  
underflow test in power_var_int() causes it to return zero if the  
result scale is too small. That's not a problem for power_var_int()'s  
only other caller, power_var(), since that limits the rscale to 1000,  
but in get_str_from_var_sci() the exponent can be much smaller,  
requiring a much larger rscale. Fix by introducing a new function to  
compute 10^exp directly, with no rscale limit. This also allows 10^exp  
to be computed more efficiently, without any numeric multiplication,  
division or rounding.  
  
Discussion: https://postgr.es/m/CAEZATCWhojfH4whaqgUKBe8D5jNHB8ytzemL-PnRx+KCTyMXmg@mail.gmail.com  

commit   : 3ab496ab8b144c20e9b03c5fc908cf973e6593cd    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 3 Aug 2021 12:26:08 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 3 Aug 2021 12:26:08 -0400    

Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.6  

commit   : 9a01a2de85e550ab40193dc45482c736dc9c4dbf    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 3 Aug 2021 12:17:57 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 3 Aug 2021 12:17:57 -0400    

Units are _truncated_ to months, but only in back branches since the  
recent commit.  
  
Reported-by: Bryn Llewellyn  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.6 to 14  

commit   : 5e531bb1d368bee9ae6671bdb16312b2d4e64b52    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 3 Aug 2021 11:58:14 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 3 Aug 2021 11:58:14 -0400    

Also create a script that can be run to update them.  
  
Reported-by: Dave Cramer  
  
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com  
  
Backpatch-through: 9.6  

commit   : 763b95cecc747aa95161b7e13102f087aa5a6b21    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 3 Aug 2021 11:27:32 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 3 Aug 2021 11:27:32 -0400    

The previous wording was unclear about the steps needed to upgrade  
extensions, and how to update them after pg_upgrade.  
  
Reported-by: Dave Cramer  
  
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com  
  
Backpatch-through: 9.6  

commit   : 78aa655d77e460a704f0af1cf5b223572a836a07    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 3 Aug 2021 10:57:32 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 3 Aug 2021 10:57:32 -0400    

This is only possible with GNU split, not other versions like BSD split.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.6  

commit   : 5cf350ce02278da488e9eb4825a573d86d6d9fcc    
  
author   : Dean Rasheed <[email protected]>    
date     : Sat, 31 Jul 2021 11:31:18 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Sat, 31 Jul 2021 11:31:18 +0100    

This fixes a couple of related problems that arise when raising  
numbers to very large powers.  
  
Firstly, when raising a negative number to a very large integer power,  
the result should be well-defined, but the previous code would only  
cope if the exponent was small enough to go through power_var_int().  
Otherwise it would throw an internal error, attempting to take the  
logarithm of a negative number. Fix this by adding suitable handling  
to the general case in power_var() to cope with negative bases,  
checking for integer powers there.  
  
Next, when raising a (positive or negative) number whose absolute  
value is slightly less than 1 to a very large power, the result should  
approach zero as the power is increased. However, in some cases, for  
sufficiently large powers, this would lose all precision and return 1  
instead of 0. This was due to the way that the local_rscale was being  
calculated for the final full-precision calculation:  
  
  local_rscale = rscale + (int) val - ln_dweight + 8  
  
The first two terms on the right hand side are meant to give the  
number of significant digits required in the result ("val" being the  
estimated result weight). However, this failed to account for the fact  
that rscale is clipped to a maximum of NUMERIC_MAX_DISPLAY_SCALE  
(1000), and the result weight might be less then -1000, causing their  
sum to be negative, leading to a loss of precision. Fix this by  
forcing the number of significant digits calculated to be nonnegative.  
It's OK for it to be zero (when the result weight is less than -1000),  
since the local_rscale value then includes a few extra digits to  
ensure an accurate result.  
  
Finally, add additional underflow checks to exp_var() and power_var(),  
so that they consistently return zero for cases like this where the  
result is indistinguishable from zero. Some paths through this code  
already returned zero in such cases, but others were throwing overflow  
errors.  
  
Dean Rasheed, reviewed by Yugo Nagata.  
  
Discussion: http://postgr.es/m/CAEZATCW6Dvq7+3wN3tt5jLj-FyOcUgT5xNoOqce5=6Su0bCR0w@mail.gmail.com  

commit   : fa27389c53ca095f52b146d8bdfeb62e8d7f4fb6    
  
author   : John Naylor <[email protected]>    
date     : Fri, 30 Jul 2021 18:52:55 -0400    
  
committer: John Naylor <[email protected]>    
date     : Fri, 30 Jul 2021 18:52:55 -0400    

On versions 11 and earlier, MinGW32 has a separate expect file for the  
regression test changed by master commit 5fcf3945b.  

commit   : cfcb0ceabde11dc6bf57185f72a2b14132631dfd    
  
author   : John Naylor <[email protected]>    
date     : Fri, 30 Jul 2021 13:50:23 -0400    
  
committer: John Naylor <[email protected]>    
date     : Fri, 30 Jul 2021 13:50:23 -0400    

The previous coding guarded against -INT_MAX instead of INT_MIN,  
leading to -2147483648 being rejected as out of range.  
  
Per bug #17128 from Kevin Sweet  
  
Discussion: https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.org  
Reviewed-by: Tom Lane  
Backpatch to all supported branches  

commit   : 32d182dd0da9628a4bc1515b69694d6e361a8de4    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 29 Jul 2021 01:35:52 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 29 Jul 2021 01:35:52 +0900    

If a file is truncated, we must update minRecoveryPoint. Once a file is  
truncated, there's no going back; it would not be safe to stop recovery  
at a point earlier than that anymore.  
  
Commit 7bffc9b7bf changed xact_redo_commit() so that it updates  
minRecoveryPoint on truncation, but forgot to change xact_redo_abort().  
  
Back-patch to all supported versions.  
  
Reported-by: [email protected]  
Author: Fujii Masao  
Reviewed-by: Heikki Linnakangas  
Discussion: https://postgr.es/m/b029fce3-4fac-4265-968e-16f36ff4d075.mengjuan.cmj@alibaba-inc.com  

commit   : 85ec6c32265013ad2de145c3684fb026e094f0cb    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 27 Jul 2021 15:44:12 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 27 Jul 2021 15:44:12 -0400    

This changes the behavior of examining the pg_file_settings view after  
changing a config option that requires restart.  The user needs to know  
that any change of such options does not take effect until a restart,  
and this worked correctly if the line is edited without removing it.  
However, for the case where the line is removed altogether, the flag  
doesn't get set, because a flag was only set in set_config_option, but  
that's not called for lines removed.  Repair.  
  
(Ref.: commits 62d16c7fc561 and a486e35706ea)  
  
Author: Álvaro Herrera <[email protected]>  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 78c21d79d72aa38cfe4a16b232aaf9d723b20378    
  
author   : Fujii Masao <[email protected]>    
date     : Wed, 28 Jul 2021 01:25:53 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Wed, 28 Jul 2021 01:25:53 +0900    

The error messages using the word "non-negative" are confusing  
because it's ambiguous about whether it accepts zero or not.  
This commit improves those error messages by replacing it with  
less ambiguous word like "greater than zero" or  
"greater than or equal to zero".  
  
Also this commit added the note about the word "non-negative" to  
the error message style guide, to help writing the new error messages.  
  
When postgres_fdw option fetch_size was set to zero, previously  
the error message "fetch_size requires a non-negative integer value"  
was reported. This error message was outright buggy. Therefore  
back-patch to all supported versions where such buggy error message  
could be thrown.  
  
Reported-by: Hou Zhijie  
Author: Bharath Rupireddy  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao  
Discussion: https://postgr.es/m/OS0PR01MB5716415335A06B489F1B3A8194569@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 088dbf3bc40bd866da71e07bef8963c81dbb14b9    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 26 Jul 2021 22:38:14 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 26 Jul 2021 22:38:14 -0400    

Add pg_resetxlog -u option to set the oldest xid in pg_control.  
Previously -x set this value be -2 billion less than the -x value.  
However, this causes the server to immediately scan all relation's  
relfrozenxid so it can advance pg_control's oldest xid to be inside the  
autovacuum_freeze_max_age range, which is inefficient and might disrupt  
diagnostic recovery.  pg_upgrade will use this option to better create  
the new cluster to match the old cluster.  
  
Reported-by: Jason Harvey, Floris Van Nee  
  
Discussion: https://postgr.es/m/[email protected], [email protected]  
  
Author: Bertrand Drouvot  
  
Backpatch-through: 9.6  

commit   : 8e5be9cfe70e2b7042c7e29f859a05abad57d5e1    
  
author   : Fujii Masao <[email protected]>    
date     : Mon, 16 Nov 2020 18:27:51 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Mon, 16 Nov 2020 18:27:51 +0900    

This commit changes the startup process in the standby server so that  
it handles the interrupt signals after waiting for wal_retrieve_retry_interval  
on the latch and resetting it, before entering another wait on the latch.  
This change causes the standby server to promptly handle interrupt signals.  
  
Otherwise, previously, there was the case where the standby needs to  
wait extra five seconds to shutdown when the shutdown request arrived  
while the startup process was waiting for wal_retrieve_retry_interval  
on the latch.  
  
Author: Fujii Masao, but implementation idea is from Soumyadeep Chakraborty  
Reviewed-by: Soumyadeep Chakraborty  
Discussion: https://postgr.es/m/[email protected]  
  
Per discussion of BUG #17073, back-patch to all supported versions.  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1861390e6cf52bd36e100a64bfc5449dd82377fb    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 24 Jul 2021 18:35:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 24 Jul 2021 18:35:52 -0400    

We have an implementation restriction that PREPARE TRANSACTION can't  
handle cases where both session-lifespan and transaction-lifespan locks  
are held on the same lockable object.  (That's because we'd otherwise  
need to acquire a new PROCLOCK entry during post-prepare cleanup, which  
is an operation that might fail.  The situation can only arise with odd  
usages of advisory locks, so removing the restriction is probably not  
worth the amount of effort it would take.)  AtPrepare_Locks attempted  
to enforce this, but its logic was many bricks shy of a load, because  
it only detected cases where the session and transaction locks had the  
same lockmode.  Locks of different modes on the same object would lead  
to the rather unhelpful message "PANIC: we seem to have dropped a bit  
somewhere".  
  
To fix, build a transient hashtable with one entry per locktag,  
not one per locktag + mode, and use that to detect conflicts.  
  
Per bug #17122 from Alexander Pyhalov.  This bug is ancient,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7e09b504d0232c81654d4da1b8d0ab724d941fa9    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 24 Jul 2021 13:41:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 24 Jul 2021 13:41:17 -0400    

We previously took a hard-line attitude that callers should never print  
a null string pointer, and doing so is worthy of an assertion failure  
or crash.  However, we've long since flushed out any easy-to-find bugs  
of that nature.  What remains is a lot of code that perhaps could fail  
that way in hard-to-reach corner cases.  For example, in something as  
simple as  
    ereport(ERROR,  
            (errcode(ERRCODE_UNDEFINED_OBJECT),  
             errmsg("constraint \"%s\" for table \"%s\" does not exist",  
                    conname, get_rel_name(relid))));  
one must wonder whether it's completely guaranteed that get_rel_name  
cannot return NULL in this context.  If such a situation did occur,  
the existing policy converts what might be a pretty minor bug into  
a server crash condition.  This is not good for robustness.  
  
Hence, let's follow the lead of glibc and print "(null)" instead  
of failing.  We should, of course, still consider it a bug if that  
behavior is reachable in ordinary use; but crashing seems less  
desirable than not crashing.  
  
This fix works across-the-board in v12 and up, where we always use  
src/port/snprintf.c.  Before that, on most platforms we're at the mercy  
of the local libc, but it appears that Solaris 10 is the only supported  
platform where we'd still get a crash.  Most other platforms such as  
*BSD, macOS, and Solaris 11 have adopted glibc's behavior at some  
point.  (AIX and HPUX just print "" not "(null)", but that's close  
enough.)  I've not checked what Windows' native printf would do, but  
it doesn't matter because we've long used snprintf.c on that platform.  
  
In v12 and up, also const-ify related code so that we're not casting  
away const on the constant string.  This is just neatnik-ism, since  
next to no compilers will warn about that.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : dffec69feea8320e21c76355985fcb83e640cd98    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 20 Jul 2021 13:01:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 20 Jul 2021 13:01:48 -0400    

If an error was raised during our initial attempt to check whether  
a successfully-compiled expression is "simple", subsequent calls of  
exec_stmt_execsql would suppose that stmt->mod_stmt was already computed  
when it had not been.  This could lead to assertion failures in debug  
builds; in production builds the effect would typically be to act as  
if INTO STRICT had been specified even when it had not been.  Of course  
that only matters if the subsequent attempt to execute the expression  
succeeds, so that the problem can only be reached by fixing a failure  
in some referenced, inline-able SQL function and then retrying the  
calling plpgsql function in the same session.  
  
(There might be even-more-obscure ways to change the expression's  
behavior without changing the plpgsql function, but that one seems  
like the only one people would be likely to hit in practice.)  
  
The most foolproof way to fix this would be to arrange for  
exec_prepare_plan to not set expr->plan until we've finished the  
subsidiary simple-expression check.  But it seems hard to do that  
without creating reference-count leak issues.  So settle for documenting  
the hazard in a comment and fixing exec_stmt_execsql to test separately  
for whether it's computed stmt->mod_stmt.  (That adds a test-and-branch  
per execution, but hopefully that's negligible in context.)  In v11 and  
up, also fix exec_stmt_call which had a variant of the same issue.  
  
Per bug #17113 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : cf6e5c7ebbab5fb5ad18f2fc99e18a7cdd576e73    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 17 Jul 2021 11:52:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 17 Jul 2021 11:52:54 -0400    

We had documentation of default_transaction_isolation et al,  
but for some reason not of transaction_isolation et al.  
AFAICS this is just an ancient oversight, so repair.  
  
Per bug #17077 from Yanliang Lei.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d0e44bae4923cebe08fd03f8ac6cb42757eec480    
  
author   : David Rowley <[email protected]>    
date     : Tue, 13 Jul 2021 13:32:10 +1200    
  
committer: David Rowley <[email protected]>    
date     : Tue, 13 Jul 2021 13:32:10 +1200    

41469253e went to the trouble of removing a theoretical bug from  
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's  
make this a little more robust by also setting the tuple to NULL so that  
should we be called again we won't end up doing a pfree on the already  
pfree'd tuple. Per advice from Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6, same as 41469253e  

commit   : 87b7a652b3a2a291ec46a6a4592fbbd7e0a96529    
  
author   : David Rowley <[email protected]>    
date     : Tue, 13 Jul 2021 12:46:52 +1200    
  
committer: David Rowley <[email protected]>    
date     : Tue, 13 Jul 2021 12:46:52 +1200    

This fixes a theoretical bug in tuplesort.c which, if a bounded sort was  
used in combination with a byval Datum sort (tuplesort_begin_datum), when  
switching the sort to a bounded heap in make_bounded_heap(), we'd call  
free_sort_tuple().  The problem was that when sorting Datums of a byval  
type, the tuple is NULL and free_sort_tuple() would free the memory for it  
regardless of that.  This would result in a crash.  
  
Here we fix that simply by adding a check to see if the tuple is NULL  
before trying to disassociate and free any memory belonging to it.  
  
The reason this bug is only theoretical is that nowhere in the current  
code base do we do tuplesort_set_bound() when performing a Datum sort.  
However, let's backpatch a fix for this as if any extension uses the code  
in this way then it's likely to cause problems.  
  
Author: Ronan Dunklau  
Discussion: https://postgr.es/m/CAApHDvpdoqNC5FjDb3KUTSMs5dg6f+XxH4Bg_dVcLi8UYAG3EQ@mail.gmail.com  
Backpatch-through: 9.6, oldest supported version  

commit   : fa84ff75a3417a4852e85b15395094e69d4ca7ab    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 12 Jul 2021 22:07:35 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 12 Jul 2021 22:07:35 +0200    

commit   : 00e77ef76c5cf0e400db38127b01d20a8ba759e4    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 12 Jul 2021 11:13:33 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 12 Jul 2021 11:13:33 +0300    

This should have been removed in commit 7e30c186da, which split the loop  
into two. Only the first loop uses the 'from' variable; updating it in  
the second loop is bogus. It was never read after the first loop, so this  
was harmless and surely optimized away by the compiler, but let's be tidy.  
  
Backpatch to all supported versions.  
  
Author: Ranier Vilela  
Discussion: https://www.postgresql.org/message-id/CAEudQAoWq%2BAL3BnELHu7gms2GN07k-np6yLbukGaxJ1vY-zeiQ%40mail.gmail.com  

commit   : 734be249d2c8aab31b25bcb073a1e98692bc73f6    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 11 Jul 2021 12:54:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 11 Jul 2021 12:54:24 -0400    

Although we were careful to lock the object being added or dropped,  
we failed to get any sort of lock on the extension itself.  This  
allowed the ALTER to proceed in parallel with a DROP EXTENSION,  
which is problematic for a couple of reasons.  If both commands  
succeeded we'd be left with a dangling link in pg_depend, which  
would cause problems later.  Also, if the ALTER failed for some  
reason, it might try to print the extension's name, and that could  
result in a crash or (in older branches) a silly error message  
complaining about extension "(null)".  
  
Per bug #17098 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f8abf6944b12c9ed01062a5163385f6c49f0f6ef    
  
author   : Dean Rasheed <[email protected]>    
date     : Sat, 10 Jul 2021 12:51:22 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Sat, 10 Jul 2021 12:51:22 +0100    

This fixes an overflow error when using the numeric * operator if the  
result has more than 16383 digits after the decimal point by rounding  
the result. Overflow errors should only occur if the result has too  
many digits *before* the decimal point.  
  
Discussion: https://postgr.es/m/CAEZATCUmeFWCrq2dNzZpRj5+6LfN85jYiDoqm+ucSXhb9U2TbA@mail.gmail.com  

commit   : 3c612d9f66385f95d6e7a33e77ffac7bf6156a85    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 Jul 2021 16:59:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 9 Jul 2021 16:59:08 -0400    

I incorrectly diagnosed the reason why hoverfly is unhappy.  
Looking closer, it appears that it fails to link libldap  
unless libssl is also present; so the problem was my  
idea of clearing LIBS before making the check.  Revert  
to essentially the original coding, except that instead  
of failing when libldap_r isn't there, use libldap.  
  
Per buildfarm member hoverfly.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8c9c208990b588c652c13b019fb15d9da55d6306    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 Jul 2021 14:15:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 9 Jul 2021 14:15:41 -0400    

In commit d0a02bdb8, I'd supposed that uniformly probing for  
ldap_bind would make the intent clearer.  However, that seems  
not to work on AIX, for obscure reasons (maybe it's a macro  
there?).  Revert to the former behavior of probing  
ldap_simple_bind for thread-safe cases and ldap_bind otherwise.  
  
Per buildfarm member hoverfly.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : cd5d3aefa6d04dd35f6e6b9b047f6f2c1a903ad9    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 Jul 2021 12:38:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 9 Jul 2021 12:38:55 -0400    

The separate libldap_r is gone and libldap itself is now always  
thread-safe.  Unfortunately there seems no easy way to tell by  
inspection whether libldap is thread-safe, so we have to take  
it on faith that libldap is thread-safe if there's no libldap_r.  
That should be okay, as it appears that libldap_r was a standard  
part of the installation going back at least 20 years.  
  
Report and patch by Adrian Ho.  Back-patch to all supported  
branches, since people might try to build any of them with  
a newer OpenLDAP.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f0271cb15465e7992b48a7d59583b11f61b64e88    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 Jul 2021 11:02:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 9 Jul 2021 11:02:26 -0400    

Since the executor can't cope with a utility statement appearing  
as a node of a plan tree, we can't support cases where a rewrite  
rule inserts a NOTIFY into an INSERT/UPDATE/DELETE command appearing  
in a WITH clause of a larger query.  (One can imagine ways around  
that, but it'd be a new feature not a bug fix, and so far there's  
been no demand for it.)  RewriteQuery checked for this, but it  
missed the case where the DML command rewrites to *only* a NOTIFY.  
That'd lead to crashes later on in planning.  Add the missed check,  
and improve the level of testing of this area.  
  
Per bug #17094 from Yaoguang Chen.  It's been busted since WITH  
was introduced, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 996e69c1addcb96ca3cc9278142f418c3bd06c00    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 9 Jul 2021 17:51:48 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Fri, 9 Jul 2021 17:51:48 +1200    

Commit 6753333f stopped using semaphores as the sleep/wake mechanism for  
heavyweight locks, but some obsolete references to that scheme remained  
in comments.  As with similar commit 25b93a29, back-patch all the way.  
  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGLafjB1uzXcy%3D%3D2L3cy7rjHkqOVn7qRYGBjk%3D%3DtMJE7Yg%40mail.gmail.com  

commit   : 3e474a7087cf65c45b88b459bd5aa7a8aa70df72    
  
author   : David Rowley <[email protected]>    
date     : Fri, 9 Jul 2021 15:14:26 +1200    
  
committer: David Rowley <[email protected]>    
date     : Fri, 9 Jul 2021 15:14:26 +1200    

I accidentally missed adding this when adjusting 55fe60938 for back  
patching.  This adjustment was made for 9.6 to 13. 14 and master are not  
affected.  
  
Discussion: https://postgr.es/m/CAApHDvp=twCsGAGQG=A=cqOaj4mpknPBW-EZB-sd+5ZS5gCTtA@mail.gmail.com  

commit   : 674ee3b7669444dbfd9a6ec47aa49ead8444349e    
  
author   : David Rowley <[email protected]>    
date     : Fri, 9 Jul 2021 14:05:24 +1200    
  
committer: David Rowley <[email protected]>    
date     : Fri, 9 Jul 2021 14:05:24 +1200    

Due to how pg_size_pretty(bigint) was implemented, it's possible that when  
given a negative number of bytes that the returning value would not match  
the equivalent positive return value when given the equivalent positive  
number of bytes.  This was due to two separate issues.  
  
1. The function used bit shifting to convert the number of bytes into  
larger units.  The rounding performed by bit shifting is not the same as  
dividing.  For example -3 >> 1 = -2, but -3 / 2 = -1.  These two  
operations are only equivalent with positive numbers.  
  
2. The half_rounded() macro rounded towards positive infinity.  This meant  
that negative numbers rounded towards zero and positive numbers rounded  
away from zero.  
  
Here we fix #1 by dividing the values instead of bit shifting.  We fix #2  
by adjusting the half_rounded macro always to round away from zero.  
  
Additionally, adjust the pg_size_pretty(numeric) function to be more  
explicit that it's using division rather than bit shifting.  A casual  
observer might have believed bit shifting was used due to a static  
function being named numeric_shift_right.  However, that function was  
calculating the divisor from the number of bits and performed division.  
Here we make that more clear.  This change is just cosmetic and does not  
affect the return value of the numeric version of the function.  
  
Here we also add a set of regression tests both versions of  
pg_size_pretty() which test the values directly before and after the  
function switches to the next unit.  
  
This bug was introduced in 8a1fab36a. Prior to that negative values were  
always displayed in bytes.  
  
Author: Dean Rasheed, David Rowley  
Discussion: https://postgr.es/m/CAEZATCXnNW4HsmZnxhfezR5FuiGgp+mkY4AzcL5eRGO4fuadWg@mail.gmail.com  
Backpatch-through: 9.6, where the bug was introduced.  

commit   : 67f925bbd9de4ea5d775a72a89d768db38c976ae    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 6 Jul 2021 12:36:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 6 Jul 2021 12:36:13 -0400    

As in 50371df26, this is a bad idea since the callback can't really  
know what error is being thrown and thus whether or not it is safe  
to attempt catalog accesses.  Rather than pushing said accesses into  
the mainline code where they'd usually be a waste of cycles, we can  
look at the query's rangetable instead.  
  
This change does mean that we'll be printing query aliases (if any  
were used) rather than the table or column's true name.  But that  
doesn't seem like a bad thing: it's certainly a more useful definition  
in self-join cases, for instance.  In any case, it seems unlikely that  
any applications would be depending on this detail, so it seems safe  
to change.  
  
Patch by me.  Original complaint by Andres Freund; Bharath Rupireddy  
noted the connection to conversion_error_callback.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c1123be619fca66c63b1eeef7846649736ca9199    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 6 Jul 2021 10:34:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 6 Jul 2021 10:34:51 -0400    

Our code has supported fractional-minute UTC offsets for ages, but  
there was no mention of the possibility in the main docs, and only  
a very indirect reference in Appendix B.  Improve that.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b82eabec300e987e5147c535e93b21f1ef0ea258    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Jul 2021 16:51:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Jul 2021 16:51:57 -0400    

Commit 03ffc4d6d added logic to bypass all caching behavior in  
LookupOpclassInfo when CLOBBER_CACHE_ALWAYS is enabled.  It doesn't  
look like I stopped to think much about what that would cost, but  
recent investigation shows that the cost is enormous: it roughly  
doubles the time needed for cache-clobber test runs.  
  
There does seem to be value in this behavior when trying to test  
the opclass-cache loading logic itself, but for other purposes the  
cost is excessive.  Hence, let's back off to doing this only when  
debug_invalidate_system_caches_always is at least 3; or in older  
branches, when CLOBBER_CACHE_RECURSIVELY is defined.  
  
While here, clean up some other minor issues in LookupOpclassInfo.  
Re-order the code so we aren't left with broken cache entries (leading  
to later core dumps) in the unlikely case that we suffer OOM while  
trying to allocate space for a new entry.  (That seems to be my  
oversight in 03ffc4d6d.)  Also, in >= v13, stop allocating one array  
entry too many.  That's evidently left over from sloppy reversion in  
851b14b0c.  
  
Back-patch to all supported branches, mainly to reduce the runtime  
of cache-clobbering buildfarm animals.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6733da32c68df58b0fe325fc2952a185e1d85ac7    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 4 Jul 2021 20:59:34 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 4 Jul 2021 20:59:34 +0900    

Author: Greg Sabino Mullane  
Discussion: https://postgr.es/m/CAKAnmmJYH2FBn_+Vwd2FD5SaKn8hjhAXOCHpZc6n4wXaUaW_SA@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 1c84f355ac58fca53752f6335309b48ce97d8d73    
  
author   : David Rowley <[email protected]>    
date     : Sun, 4 Jul 2021 22:32:46 +1200    
  
committer: David Rowley <[email protected]>    
date     : Sun, 4 Jul 2021 22:32:46 +1200    

Document that setting maintenance_work_mem to values over 1GB has no  
effect on VACUUM.  
  
Reported-by: Martín Marqués  
Author: Laurenz Albe  
Discussion: https://postgr.es/m/CABeG9LsZ2ozUMcqtqWu_-GiFKB17ih3p8wBHXcpfnHqhCnsc7A%40mail.gmail.com  
Backpatch-through: 9.6, oldest supported release  

commit   : 58f759fd030a2c2b067107140474eaf59c8f168a    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 2 Jul 2021 20:42:45 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 2 Jul 2021 20:42:45 -0400    

Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.6  

commit   : 1f7ea06d7eedd37e5e6bf8ddeaf14d3c303c596a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 1 Jul 2021 15:43:31 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 1 Jul 2021 15:43:31 -0400    

commit   : cbd5d7c852dcab56c7907ba07d45ef97eb28e158    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 1 Jul 2021 14:51:54 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 1 Jul 2021 14:51:54 -0400    

These are the same as world and install-world respectively, but without  
building or installing the documentation. There are many reasons for  
wanting to be able to do this, including speed, lack of documentation  
building tools, and wanting to build other formats of the documentation.  
Plans for simplifying the buildfarm client code include using these  
targets.  
  
Backpatch to all live branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d173a469922074778cbfecbebcb5020b10c03b0f    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 1 Jul 2021 08:48:24 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 1 Jul 2021 08:48:24 -0400    

The prove_installcheck recipe in src/Makefile.global.in was emitting  
bogus paths for a couple of elements when used with PGXS. Here we create  
a separate recipe for the PGXS case that does it correctly. We also take  
the opportunity to make the make the file more readable by breaking up  
the prove_installcheck and prove_check recipes across several lines, and  
to remove the setting for REGRESS_SHLIB to src/test/recovery/Makefile,  
which is the only set of tests that actually need it.  
  
Backpatch to all live branches  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 68bad2333f7a4436861ec283b030578decca50bf    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 30 Jun 2021 11:49:36 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 30 Jun 2021 11:49:36 +0900    

Reaching PITR on such a transaction would cause the generation of a LOG  
message mentioning a transaction committed, not aborted.  
  
Oversight in 4f1b890.  
  
Author: Simon Riggs  
Discussion: https://postgr.es/m/CANbhV-GJ6KijeCgdOrxqMCQ+C8QiK657EMhCy4csjrPcEUFv_Q@mail.gmail.com  
Backpatch-through: 9.6  

commit   : b54be47cdc2d225d8134b197edae9c075146e76d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Jun 2021 14:17:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Jun 2021 14:17:42 -0400    

Causing a core dump on out-of-memory seems pretty unfriendly,  
and surely is far outside the expected behavior of a general-purpose  
library.  Just print an error message (as we did already) and return.  
These functions unfortunately don't have an error return convention,  
but code using them is probably just looking for a quick-n-dirty  
print method and wouldn't bother to check anyway.  
  
Although these functions are semi-deprecated, it still seems  
appropriate to back-patch this.  In passing, also back-patch  
b90e6cef1, just to reduce cosmetic differences between the  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 21257a8f6dcb1466ce78421286a075b75bf82f4f    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 28 Jun 2021 11:17:30 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 28 Jun 2021 11:17:30 +0900    

83158f7 has improved index_set_state_flags() so as it is possible to use  
transactional updates when updating pg_index state flags, but there was  
not really a test case which stressed directly the possibility it fixed.  
This commit adds such a test, using a predicate that looks valid in  
appearance but calls a stable function.  
  
Author: Andrey Lepikhov  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : d3d0cbeb62320e0629596f6efb5921b36321c57f    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 28 Jun 2021 10:43:13 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 28 Jun 2021 10:43:13 +0900    

3c84046 is the original commit that introduced index_set_state_flags(),  
where the presence of SnapshotNow made necessary the use of an in-place  
update.  SnapshotNow has been removed in 813fb03, so there is no actual  
reasons to not make this operation transactional.  
  
As reported by Andrey, it is possible to trigger the assertion of this  
routine expecting no transactional updates when switching the pg_index  
state flags, using a predicate mark as immutable but calling stable or  
volatile functions.  83158f7 has been around for a couple of months on  
HEAD now with no issues found related to it, so it looks safe enough for  
a backpatch.  
  
Reported-by: Andrey Lepikhov  
Author: Michael Paquier  
Reviewed-by: Anastasia Lubennikova  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : de589c11297c575fa88efe69f78394d2c93522dc    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 27 Jun 2021 12:45:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 27 Jun 2021 12:45:04 -0400    

specscanner.l leaked a kilobyte of memory per token of the spec file.  
Apparently somebody thought that the introductory code block would be  
executed once; but it's once per yylex() call.  
  
A couple of functions in isolationtester.c leaked small amounts of  
memory due to not bothering to free one-time allocations.  Might  
as well improve these so that valgrind gives this program a clean  
bill of health.  Also get rid of an ugly static variable.  
  
Coverity complained about one of the one-time leaks, which led me  
to try valgrind'ing isolationtester, which led to discovery of the  
larger leak.  

commit   : 9c7a150aec71702be24174d3a73533030356374c    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 25 Jun 2021 13:59:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 25 Jun 2021 13:59:38 -0400    

It's not really necessary for this function to open or lock the  
relation associated with the pg_policy entry it's modifying.  The  
error checks it's making on the rel are if anything counterproductive  
(e.g., if we don't want to allow installation of policies on system  
catalogs, here is not the place to prevent that).  In particular, it  
seems just wrong to insist on an ownership check.  That has the net  
effect of forcing people to use superuser for DROP OWNED BY, which  
surely is not an effect we want.  Also there is no point in rebuilding  
the dependencies of the policy expressions, which aren't being  
changed.  Lastly, locking the table also seems counterproductive; it's  
not helping to prevent race conditions, since we failed to re-read the  
pg_policy row after acquiring the lock.  That means that concurrent  
DDL would likely result in "tuple concurrently updated/deleted"  
errors; which is the same behavior this code will produce, with less  
overhead.  
  
Per discussion of bug #17062.  Back-patch to all supported versions,  
as the failure cases this eliminates seem just as undesirable in 9.6  
as in HEAD.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e0a7036e18a3d321bbe88061d2e309ee1c527b84    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 24 Jun 2021 11:30:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 24 Jun 2021 11:30:32 -0400    

This back-branch test script was later absorbed into  
insert-conflict-specconflict.spec, which required some stabilization  
in commit 741d7f104, so perhaps it's not surprising that it needs a  
bit of love too.  
  
It's odd though that we hadn't seen it fail before now, because  
I thought that 741d7f104 did not change isolationtester's timing  
behavior for scripts without any annotation markers.  In any case,  
this script is racy on its face, so add an annotation to force stable  
reporting order.  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=piculet&dt=2021-06-24%2009%3A54%3A56  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=petalura&dt=2021-06-24%2010%3A10%3A00  

commit   : 5956795cb5befdc7b5dab3e1e781b74fbc3590e8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 24 Jun 2021 11:19:03 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 24 Jun 2021 11:19:03 +0300    

In previous commit, I missed that relmap_redo() was also not acquiring the  
RelationMappingLock. Thanks to Thomas Munro for pointing that out.  
  
Backpatch-through: 9.6, like previous commit.  
Discussion: https://www.postgresql.org/message-id/CA%2BhUKGLev%3DPpOSaL3WRZgOvgk217et%2BbxeJcRr4eR-NttP1F6Q%40mail.gmail.com  

commit   : 85ae8ccb2fb330785c6503316635dc7256cbe495    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 24 Jun 2021 10:45:23 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 24 Jun 2021 10:45:23 +0300    

Contrary to the comment here, POSIX does not guarantee atomicity of a  
read(), if another process calls write() concurrently. Or at least Linux  
does not. Add locking to load_relmap_file() to avoid the race condition.  
  
Fixes bug #17064. Thanks to Alexander Lakhin for the report and test case.  
  
Backpatch-through: 9.6, all supported versions.  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 4be39ef9cbc5afc6078bdf9253e5981da6e0cf5f    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 24 Jun 2021 10:22:46 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 24 Jun 2021 10:22:46 +0530    

Reported-by: Simon Riggs  
Author: Takamichi Osumi  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : c835be32cc9c3f685ae093a35d0368f175ed2a33    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 23 Jun 2021 19:24:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 23 Jun 2021 19:24:36 -0400    

I happened to notice that if compiled --with-gssapi, 9.6's  
contrib/pgcrypto tests report memory stomps for some SHA operations.  
  
Both MEMORY_CONTEXT_CHECKING and valgrind agree there's a problem,  
though nothing crashes; it appears that the buffer overrun  
only extends into alignment padding, at least on 64-bit hardware.  
  
Investigation found that pgcrypto's references to SHA224_Init  
et al were being captured by the system OpenSSL library, which  
of course has slightly incompatible definitions of those functions.  
We long ago noticed this problem with respect to the sibling  
functions SHA256_Init and so on, and commit 56f44784f introduced  
renaming macros to dodge the problem for those.  However, it didn't  
cover the SHA224 family because we didn't use that at the time.  
When commit 1abf76e82 added those awhile later, it neglected to add  
a similar renaming macro.  Better late than never, so do so now.  
  
This appears to affect all branches 8.2 - 9.6, so it's surprising  
nobody noticed before now.  Maybe the effect is somehow specific  
to the way RHEL8 intertwines its GSS and SSL libraries?  Anyway,  
we refactored all this stuff in v10, so newer branches don't have  
the problem.  

commit   : ad9827a90d9001e841dfb8b948f33917331d4a5b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 23 Jun 2021 18:41:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 23 Jun 2021 18:41:39 -0400    

For no obvious reason, isolationtester has always insisted that  
session and step names be written with double quotes.  This is  
fairly tedious and does little for test readability, especially  
since the names that people actually choose almost always look  
like normal identifiers.  Hence, let's tweak the lexer to allow  
SQL-like identifiers not only double-quoted strings.  
  
(They're SQL-like, not exactly SQL, because I didn't add any  
case-folding logic.  Also there's no provision for U&"..." names,  
not that anyone's likely to care.)  
  
There is one incompatibility introduced by this change: if you write  
"foo""bar" with no space, that used to be taken as two identifiers,  
but now it's just one identifier with an embedded quote mark.  
  
I converted all the src/test/isolation/ specfiles to remove  
unnecessary double quotes, but stopped there because my  
eyes were glazing over already.  
  
Like 741d7f104, back-patch to all supported branches, so that this  
isn't a stumbling block for back-patching isolation test changes.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 16492f5cc34663ab3148248ebfc987806a6a9fbe    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 23 Jun 2021 14:27:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 23 Jun 2021 14:27:13 -0400    

The syntax summaries for CREATE FUNCTION and allied commands  
made it look like LEAKPROOF is an alternative to  
IMMUTABLE/STABLE/VOLATILE, when of course it is an orthogonal  
option.  Improve that.  
  
Per gripe from aazamrafeeque0.  Thanks to David Johnston for  
suggestions.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 006a829b2d1427974a4d7ae58f1191be2d0ae705    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 23 Jun 2021 14:01:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 23 Jun 2021 14:01:33 -0400    

Our uses of gss_display_status() and gss_display_name() assumed  
that the gss_buffer_desc strings returned by those functions are  
null-terminated.  It appears that they generally are, given the  
lack of field complaints up to now.  However, the available  
documentation does not promise this, and some man pages  
for gss_display_status() show examples that rely on the  
gss_buffer_desc.length field instead of expecting null  
termination.  Also, we now have a report that on some  
implementations, clang's address sanitizer is of the opinion  
that the byte after the specified length is undefined.  
  
Hence, change the code to rely on the length field instead.  
  
This might well be cosmetic rather than fixing any real bug, but  
it's hard to be sure, so back-patch to all supported branches.  
While here, also back-patch the v12 changes that made pg_GSS_error  
deal honestly with multiple messages available from  
gss_display_status.  
  
Per report from Sudheer H R.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e535a8899397841fa7c180ebd6517cf1bb76ef4c    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 23 Jun 2021 11:12:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 23 Jun 2021 11:12:32 -0400    

Previously, isolationtester displayed SQL query results using some  
ad-hoc code that clearly hadn't had much effort expended on it.  
Field values longer than 14 characters weren't separated from  
the next field, and usually caused misalignment of the columns  
too.  Also there was no visual separation of a query's result  
from subsequent isolationtester output.  This made test result  
files confusing and hard to read.  
  
To improve matters, let's use libpq's PQprint() function.  Although  
that's long since unused by psql, it's still plenty good enough  
for the purpose here.  
  
Like 741d7f104, back-patch to all supported branches, so that this  
isn't a stumbling block for back-patching isolation test changes.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 13f3fd9e436d27af50aaebf5a1f2440740ee93eb    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 22 Jun 2021 21:43:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 22 Jun 2021 21:43:12 -0400    

We've long contended with isolation test results that aren't entirely  
stable.  Some test scripts insert long delays to try to force stable  
results, which is not terribly desirable; but other erratic failure  
modes remain, causing unrepeatable buildfarm failures.  I've spent a  
fair amount of time trying to solve this by improving the server-side  
support code, without much success: that way is fundamentally unable  
to cope with diffs that stem from chance ordering of arrival of  
messages from different server processes.  
  
We can improve matters on the client side, however, by annotating  
the test scripts themselves to show the desired reporting order  
of events that might occur in different orders.  This patch adds  
three types of annotations to deal with (a) test steps that might or  
might not complete their waits before the isolationtester can see them  
waiting; (b) test steps in different sessions that can legitimately  
complete in either order; and (c) NOTIFY messages that might arrive  
before or after the completion of a step in another session.  We might  
need more annotation types later, but this seems to be enough to deal  
with the instabilities we've seen in the buildfarm.  It also lets us  
get rid of all the long delays that were previously used, cutting more  
than a minute off the runtime of the isolation tests.  
  
Back-patch to all supported branches, because the buildfarm  
instabilities affect all the branches, and because it seems desirable  
to keep isolationtester's capabilities the same across all branches  
to simplify possible future back-patching of tests.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0b29b41e5b9614397ba839552f35b4485ca49e0f    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 18 Jun 2021 18:00:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 18 Jun 2021 18:00:09 -0400    

Ordinarily, a pg_policy.polroles array wouldn't list the same role  
more than once; but CREATE POLICY does not prevent that.  If we  
perform DROP OWNED BY on a role that is listed more than once,  
RemoveRoleFromObjectPolicy either suffered an assertion failure  
or encountered a tuple-updated-by-self error.  Rewrite it to cope  
correctly with duplicate entries, and add a CommandCounterIncrement  
call to prevent the other problem.  
  
Per discussion, there's other cleanup that ought to happen here,  
but this seems like the minimum essential fix.  
  
Per bug #17062 from Alexander Lakhin.  It's been broken all along,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1a3d30255a4e821445927ca0949f00364de660fd    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 18 Jun 2021 12:09:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 18 Jun 2021 12:09:22 -0400    

This works fine in the "simple Query" code path; but if the  
statement is in the plan cache then it's corrupted for future  
re-execution.  Apply copyObject() to protect the original  
tree from modification, as we've done elsewhere.  
  
This narrow fix is applied only to the back branches.  In HEAD,  
the problem was fixed more generally by commit 7c337b6b5; but  
that changed ProcessUtility's API, so it's infeasible to  
back-patch.  
  
Per bug #17053 from Charles Samborski.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : ec52b886d1dd8c08993b391753d450488e18f330    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 17 Jun 2021 16:37:13 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 17 Jun 2021 16:37:13 +0200    

The original patch only targeted Python 2.6 and newer, since that is  
what we have supported in PostgreSQL 13 and newer.  For older  
branches, we need to fix it up for older Python versions.  

commit   : 009ee51af7fd6a8dd9c518f2e6d62a4f139c766a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 17 Jun 2021 14:50:42 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 17 Jun 2021 14:50:42 +0300    

One of the error paths left *members uninitialized. That's not a live  
bug, because most callers don't look at *members when the function  
returns -1, but let's be tidy. One caller, in heap_lock_tuple(), does  
"if (members != NULL) pfree(members)", but AFAICS it never passes an  
invalid 'multi' value so it should not reach that error case.  
  
The callers are also a bit inconsistent in their expectations.  
heap_lock_tuple() pfrees the 'members' array if it's not-NULL, others  
pfree() it if "nmembers >= 0", and others if "nmembers > 0". That's  
not a live bug either, because the function should never return 0, but  
add an Assert for that to make it more clear. I left the callers alone  
for now.  
  
I also moved the line where we set *nmembers. It wasn't wrong before,  
but I like to do that right next to the 'return' statement, to make it  
clear that it's always set on return.  
  
Also remove one unreachable return statement after ereport(ERROR), for  
brevity and for consistency with the similar if-block right after it.  
  
Author: Greg Nancarrow with the additional changes by me  
Backpatch-through: 9.6, all supported versions  

commit   : 9c31e4165522eb510123a05597f541dadff4e679    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 5 Jun 2021 07:16:34 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 5 Jun 2021 07:16:34 +0200    

Starting with Python 3.10, the stacktrace looks differently:  
  -  PL/Python function "subtransaction_exit_subtransaction_in_with", line 3, in <module>  
  -    s.__exit__(None, None, None)  
  +  PL/Python function "subtransaction_exit_subtransaction_in_with", line 2, in <module>  
  +    with plpy.subtransaction() as s:  
Using try/except specifically makes the error look always the same.  
  
(See https://github.com/python/cpython/pull/25719 for the discussion  
of this change in Python.)  
  
Author: Honza Horak <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/853083.1620749597%40sss.pgh.pa.us  
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1959080  

commit   : acdb523cb642e190e55719b8e4769a99fc767606    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 17 Jun 2021 11:44:35 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 17 Jun 2021 11:44:35 +0530    

In a synchronous logical setup, locking [user] catalog tables can cause  
deadlock. This is because logical decoding of transactions can lock  
catalog tables to access them so exclusively locking those in transactions  
can lead to deadlock. To avoid this users must refrain from having  
exclusive locks on catalog tables.  
  
Author: Takamichi Osumi  
Reviewed-by: Vignesh C, Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky%40alap3.anarazel.de  

commit   : 484c81bf7765862a02a2866466b140a097e36c8c    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 17 Jun 2021 11:57:44 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 17 Jun 2021 11:57:44 +0900    

This is useful for developers to find out if an isolation spec is  
over-engineered or if it needs more work by warning at the end of a  
test run if a step is not used, generating a failure with extra diffs.  
  
While on it, clean up all the specs which include steps not used in any  
permutations to simplify them.  
  
This is a backpatch of 989d23b and 06fdc4e, as it is becoming useful to  
make all the branches consistent for an upcoming patch that will improve  
the output generated by isolationtester.  
  
Author: Michael Paquier  
Reviewed-by: Asim Praveen, Melanie Plageman  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : b7cd5c5b02fa38c2f2ae9a0a3642c46e625e1b97    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 17 Jun 2021 11:01:32 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 17 Jun 2021 11:01:32 +0900    

The original purpose of the dry-run mode is to be able to print all the  
possible permutations from a spec file, but it has become less useful  
since isolation tests have improved regarding deadlock detection as one  
step not wanted by the author could block indefinitely now (originally  
the step blocked would have been detected rather quickly).  Per  
discussion, let's remove it.  
  
This is a backpatch of 9903338 for 9.6~12.  It is proving to become  
useful to have on those branches so as the code gets consistent across  
all supported versions, as a matter of improving the output generated by  
isolationtester.  
  
Author: Michael Paquier  
Reviewed-by: Asim Praveen, Melanie Plageman  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : c50596cdc9234b15359761bdeddec5395fbd57c5    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 16 Jun 2021 19:30:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 16 Jun 2021 19:30:17 -0400    

When stuffing a plan from the plancache into a Portal, one is  
not supposed to risk throwing an error between GetCachedPlan and  
PortalDefineQuery; if that happens, the plan refcount incremented  
by GetCachedPlan will be leaked.  I managed to break this rule  
while refactoring code in 9dbf2b7d7.  There is no visible  
consequence other than some memory leakage, and since nobody is  
very likely to trigger the relevant error conditions many times  
in a row, it's not surprising we haven't noticed.  Nonetheless,  
it's a bug, so rearrange the order of operations to remove the  
hazard.  
  
Noted on the way to looking for a better fix for bug #17053.  
This mistake is pretty old, so back-patch to all supported  
branches.  

commit   : e46f6a078c1a4a2293839c9c5560517b2c4e1d12    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 15 Jun 2021 15:30:11 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 15 Jun 2021 15:30:11 -0400    

TestLib::perl2host can take a file argument as well as a directory  
argument, so that code becomes substantially simpler. Also add comments  
on why we're using forward slashes, and why we're setting  
PERL_BADLANG=0.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 43acadfcebec36f4db2074e125b2af15d3afda1a    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 15 Jun 2021 09:18:38 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 15 Jun 2021 09:18:38 +0530    

During decoding for speculative inserts, we were relying for cleaning  
toast hash on confirmation records or next change records. But that  
could lead to multiple problems (a) memory leak if there is neither a  
confirmation record nor any other record after toast insertion for a  
speculative insert in the transaction, (b) error and assertion failures  
if the next operation is not an insert/update on the same table.  
  
The fix is to start queuing spec abort change and clean up toast hash  
and change record during its processing. Currently, we are queuing the  
spec aborts for both toast and main table even though we perform cleanup  
while processing the main table's spec abort record. Later, if we have a  
way to distinguish between the spec abort record of toast and the main  
table, we can avoid queuing the change for spec aborts of toast tables.  
  
Reported-by: Ashutosh Bapat  
Author: Dilip Kumar  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6, where it was introduced  
Discussion: https://postgr.es/m/CAExHW5sPKF-Oovx_qZe4p5oM6Dvof7_P+XgsNAViug15Fm99jA@mail.gmail.com  

commit   : dd53b46c78a0ac23e95f5bd1e4fb6cd011505cef    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 13 Jun 2021 14:32:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 13 Jun 2021 14:32:42 -0400    

Recent glibc versions have made mktime() fail if tm_isdst is  
inconsistent with the prevailing timezone; in particular it fails for  
tm_isdst = 1 when the zone is UTC.  (This seems wildly inconsistent  
with the POSIX-mandated treatment of "incorrect" values for the other  
fields of struct tm, so if you ask me it's a bug, but I bet they'll  
say it's intentional.)  This has been observed to cause cosmetic  
problems when pg_restore'ing an archive created in a different  
timezone.  
  
To fix, do mktime() using the field values from the archive, and if  
that fails try again with tm_isdst = -1.  This will give a result  
that's off by the UTC-offset difference from the original zone, but  
that was true before, too.  It's not terribly critical since we don't  
do anything with the result except possibly print it.  (Someday we  
should flush this entire bit of logic and record a standard-format  
timestamp in the archive instead.  That's not okay for a back-patched  
bug fix, though.)  
  
Also, guard our only other use of mktime() by having initdb's  
build_time_t() set tm_isdst = -1 not 0.  This case could only have  
an issue in zones that are DST year-round; but I think some do exist,  
or could in future.  
  
Per report from Wells Oliver.  Back-patch to all supported  
versions, since any of them might need to run with a newer glibc.  
  
Discussion: https://postgr.es/m/CAOC+FBWDhDHO7G-i1_n_hjRzCnUeFO+H-Czi1y10mFhRWpBrew@mail.gmail.com  

commit   : 84cb4be719c16f1fdecb6e16945678c379a85c01    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 13 Jun 2021 07:10:41 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 13 Jun 2021 07:10:41 -0400    

Translate path slashes on target directory path. This was confusing old  
branches, but is applied to all branches for the sake of uniformity.  
Perl is perfectly able to understand paths with forward slashes.  
  
Along the way, restore the previous archive_wait query, for the sake of  
uniformity with other tests, per gripe from Tom Lane.  

commit   : 1df6bee296ed2be0fda11ee7aa42853cf0469f8d    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 13 Jun 2021 20:08:06 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 13 Jun 2021 20:08:06 +0900    

This is similar to the work done in 8279f68 for TestLib.pm, where  
environment variables set may cause unwanted failures if using a  
temporary installation with pg_regress.  The list of variables reset is  
adjusted in each stable branch depending on what is supported.  
  
Comments are added to remember that the lists in TestLib.pm and  
pg_regress.c had better be kept in sync.  
  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : c1ffbbcbca93b3544c0b57b7ab063497794cb8ff    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 12 Jun 2021 13:29:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 12 Jun 2021 13:29:24 -0400    

Previously, a zero value for the relfilenode resulted in  
a confusing error message about "unexpected duplicate".  
This function returns NULL for other invalid relfilenode  
values, so zero should be treated likewise.  
  
It's been like this all along, so back-patch to all supported  
branches.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : dee7ad20d018354a75f26c73ba26b8487b98e642    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 12 Jun 2021 08:37:16 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 12 Jun 2021 08:37:16 -0400    

Commit caba8f0d43 wasn't quite right for msys, as demonstrated by  
several buildfarm animals, including jacana and fairywren. We need to  
use the msys perl in the archive command, but call it in such a way that  
Windows will understand the path. Furthermore, inside the copy script we  
need to convert a Windows path to an msys path.  

commit   : a78edd4b4207627bcbe5d6d6df604aea480d4326    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 12 Jun 2021 10:39:44 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 12 Jun 2021 10:39:44 +0900    

This variable was present in the list added by 9d660670, but it is not  
supported by this branch.  Issue noticed while diving into a similar  
change for pg_regress.c.  
  
Backpatch-through: 9.6  

commit   : 6cd0e55f9ffb3be400e44812fa6163a217e09bf3    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 10 Jun 2021 09:43:35 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 10 Jun 2021 09:43:35 -0400    

Per buildfarm member conchuela and Kyotaro Horiguchi, it's possible  
for the WAL segment that the cascading standby needs to be removed  
too quickly. Hopefully this will prevent that.  
  
Kyotaro Horiguchi  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : 6eb5b9ae39176a7d40003b4c2e9ca22e6b205def    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 9 Jun 2021 16:21:14 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 9 Jun 2021 16:21:14 -0400    

This only happens if (1) the new standby has no WAL available locally,  
(2) the new standby is starting from the old timeline, (3) the promotion  
happened in the WAL segment from which the new standby is starting,  
(4) the timeline history file for the new timeline is available from  
the archive but the WAL files for are not (i.e. this is a race),  
(5) the WAL files for the new timeline are available via streaming,  
and (6) recovery_target_timeline='latest'.  
  
Commit ee994272ca50f70b53074f0febaec97e28f83c4e introduced this  
logic and was an improvement over the previous code, but it mishandled  
this case. If recovery_target_timeline='latest' and restore_command is  
set, validateRecoveryParameters() can change recoveryTargetTLI to be  
different from receiveTLI. If streaming is then tried afterward,  
expectedTLEs gets initialized with the history of the wrong timeline.  
It's supposed to be a list of entries explaining how to get to the  
target timeline, but in this case it ends up with a list of entries  
explaining how to get to the new standby's original timeline, which  
isn't right.  
  
Dilip Kumar and Robert Haas, reviewed by Kyotaro Horiguchi.  
  
Discussion: http://postgr.es/m/CAFiTN-sE-jr=LB8jQuxeqikd-Ux+jHiXyh4YDiZMPedgQKup0g@mail.gmail.com  

commit   : 75212a854f991689fd6acbd51536a2912bf7461b    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 9 Jun 2021 16:16:21 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 9 Jun 2021 16:16:21 -0400    

The 'lsn' and 'wait_for_catchup' methods only exist in v10 and  
higher, but are needed in order to support a test planned test  
case for a bug that exists all the way back to v9.6. To minimize  
cross-branch differences in the test case, back-port these  
methods.  
  
Discussion: http://postgr.es/m/CA+TgmoaG5dmA_8Xc1WvbvftPjtwx5uzkGEHxE7MiJ+im9jynmw@mail.gmail.com  

commit   : 954ee4b566eebfae535905696887ffd123038fd7    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 9 Jun 2021 16:26:11 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 9 Jun 2021 16:26:11 +0900    

The set of subcommands supported by \dAp, \do and \dy was described  
incorrectly in psql's --help.  The documentation was already consistent  
with the code.  
  
Reported-by: inoas, from IRC  
Author: Matthijs van der Vleuten  
Reviewed-by: Neil Chen  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : ac600c54165631d5266c8aa7c5cb8c96ac589138    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Jun 2021 14:15:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Jun 2021 14:15:25 -0400    

An incorrectly-encoded multibyte character near the end of a string  
could cause various processing loops to run past the string's  
terminating NUL, with results ranging from no detectable issue to  
a program crash, depending on what happens to be in the following  
memory.  
  
This isn't an issue in the server, because we take care to verify  
the encoding of strings before doing any interesting processing  
on them.  However, that lack of care leaked into client-side code  
which shouldn't assume that anyone has validated the encoding of  
its input.  
  
Although this is certainly a bug worth fixing, the PG security team  
elected not to regard it as a security issue, primarily because  
any untrusted text should be sanitized by PQescapeLiteral or  
the like before being incorporated into a SQL or psql command.  
(If an app fails to do so, the same technique can be used to  
cause SQL injection, with probably much more dire consequences  
than a mere client-program crash.)  Those functions were already  
made proof against this class of problem, cf CVE-2006-2313.  
  
To fix, invent PQmblenBounded() which is like PQmblen() except it  
won't return more than the number of bytes remaining in the string.  
In HEAD we can make this a new libpq function, as PQmblen() is.  
It seems imprudent to change libpq's API in stable branches though,  
so in the back branches define PQmblenBounded as a macro in the files  
that need it.  (Note that just changing PQmblen's behavior would not  
be a good idea; notably, it would completely break the escaping  
functions' defense against this exact problem.  So we just want a  
version for those callers that don't have any better way of handling  
this issue.)  
  
Per private report from houjingyi.  Back-patch to all supported branches.  

commit   : 7cdb976324d3a111fcad1901019e27d5e75715be    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Jun 2021 13:12:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Jun 2021 13:12:35 -0400    

Back-patch a minimal subset of commits fffd651e8 and 46912d9b1,  
to support strnlen() on all platforms without adding any callers.  
This will be needed by a following bug fix.  

commit   : 066535d411af6e77e06542d8a136576603164d5d    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 3 Jun 2021 16:08:33 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 3 Jun 2021 16:08:33 -0400    

The Msys shell mangles certain patterns in its command line, so avoid  
handing arbitrary SQL to psql on the command line and instead use  
IPC::Run's redirection facility for stdin. This pattern is already  
mostly whats used, but query_poll_until() was not doing the right thing.  
  
Problem discovered on the buildfarm when a new TAP test failed on msys.  

commit   : d9525c46c89d6a0d85dca0882ced98d12081bc0e    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 3 Jun 2021 15:29:01 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 3 Jun 2021 15:29:01 +0900    

The internal SQL queries used by REFRESH MATERIALIZED VIEW CONCURRENTLY  
include some aliases for its diff and temporary relations with  
rather-generic names: diff, newdata, newdata2 and mv.  Depending on the  
queries used for the materialized view, using CONCURRENTLY could lead to  
some internal failures if the query and those internal aliases conflict.  
  
Those names have been chosen in 841c29c8.  This commit switches instead  
to a naming pattern which is less likely going to cause conflicts, based  
on an idea from Thomas Munro, by appending _$ to those aliases.  This is  
not perfect as those new names could still conflict, but at least it has  
the advantage to keep the code readable and simple while reducing the  
likelihood of conflicts to be close to zero.  
  
Reported-by: Mathis Rudolf  
Author: Bharath Rupireddy  
Reviewed-by: Bernd Helmle, Thomas Munro, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : a886e2ff2413ee6420b84077f6cb991a5d97b45b    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 3 Jun 2021 11:52:03 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 3 Jun 2021 11:52:03 +0900    

Various environment variables were not getting reset in the TAP tests,  
which would cause failures depending on the tests or the environment  
variables involved.  For example, PGSSL{MAX,MIN}PROTOCOLVERSION could  
cause failures in the SSL tests.  Even worse, a junk value of  
PGCLIENTENCODING makes a server startup fail.  The list of variables  
reset is adjusted in each stable branch depending on what is supported.  
  
While on it, simplify a bit the code per a suggestion from Andrew  
Dunstan, using a list of variables instead of doing single deletions.  
  
Reviewed-by: Andrew Dunstan, Daniel Gustafsson  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : 3eca18522e1908f7a61ab2545bb9238fce4d1ba7    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 1 Jun 2021 11:12:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 1 Jun 2021 11:12:56 -0400    

This case should be disallowed, just as FOR UPDATE with a plain  
GROUP BY is disallowed; FOR UPDATE only makes sense when each row  
of the query result can be identified with a single table row.  
However, we missed teaching CheckSelectLocking() to check  
groupingSets as well as groupClause, so that it would allow  
degenerate grouping sets.  That resulted in a bad plan and  
a null-pointer dereference in the executor.  
  
Looking around for other instances of the same bug, the only one  
I found was in examine_simple_variable().  That'd just lead to  
silly estimates, but it should be fixed too.  
  
Per private report from Yaoguang Chen.  
Back-patch to all supported branches.  

commit   : 34a65fc63e0870c7e0118e76f42b9f0996ab4195    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 28 May 2021 09:35:11 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 28 May 2021 09:35:11 -0400    

commit   : abbd70022c17f541e7d05163b80631aa722fd58e    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 28 May 2021 09:26:30 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 28 May 2021 09:26:30 -0400    

This is a long standing omission, discovered when trying to write code  
that relied on it.  
  
Backpatch to all live branches.  

commit   : 7a4f2e158c0e62e26166423c411628958cb5d474    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 27 May 2021 20:11:38 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 27 May 2021 20:11:38 +0900    

The deliverables of upstream Kerberos on Windows are installed with  
paths that do not match our MSVC scripts.  First, the include folder was  
named "inc/" in our scripts, but the upstream MSIs use "include/".  
Second, the build would fail with 64-bit environments as the libraries  
are named differently.  
  
This commit adjusts the MSVC scripts to be compatible with the latest  
installations of upstream, and I have checked that the compilation was  
able to work with the 32-bit and 64-bit installations.  
  
Special thanks to Kondo Yuta for the help in investigating the situation  
in hamerkop, which had an incorrect configuration for the GSS  
compilation.  
  
Reported-by: Brian Ye  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : 521a812f0f5c83298c92638f419970f74af86189    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 27 May 2021 14:58:23 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 27 May 2021 14:58:23 +0900    

The following parameters have been imprecise, or incorrect, about their  
description (PGC_POSTMASTER or PGC_SIGHUP):  
- autovacuum_work_mem (docs, as of 9.6~)  
- huge_page_size (docs, as of 14~)  
- max_logical_replication_workers (docs, as of 10~)  
- max_sync_workers_per_subscription (docs, as of 10~)  
- min_dynamic_shared_memory (docs, as of 14~)  
- recovery_init_sync_method (postgresql.conf.sample, as of 14~)  
- remove_temp_files_after_crash (docs, as of 14~)  
- restart_after_crash (docs, as of 9.6~)  
- ssl_min_protocol_version (docs, as of 12~)  
- ssl_max_protocol_version (docs, as of 12~)  
  
This commit adjusts the description of all these parameters to be more  
consistent with the practice used for the others.  
  
Revewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : 7777df34d7a37c40bba6e93da34bb78af48134e1    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 25 May 2021 10:11:33 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 25 May 2021 10:11:33 +0900    

SSL renegotiation is already disabled as of 48d23c72, however this does  
not prevent the server to comply with a client willing to use  
renegotiation.  In the last couple of years, renegotiation had its set  
of security issues and flaws (like the recent CVE-2021-3449), and it  
could be possible to crash the backend with a client attempting  
renegotiation.  
  
This commit takes one extra step by disabling renegotiation in the  
backend in the same way as SSL compression (f9264d15) or tickets  
(97d3a0b0).  OpenSSL 1.1.0h has added an option named  
SSL_OP_NO_RENEGOTIATION able to achieve that.  In older versions  
there is an option called SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS that  
was undocumented, and could be set within the SSL object created when  
the TLS connection opens, but I have decided not to use it, as it feels  
trickier to rely on, and it is not official.  Note that this option is  
not usable in OpenSSL < 1.1.0h as the internal contents of the *SSL  
object are hidden to applications.  
  
SSL renegotiation concerns protocols up to TLSv1.2.  
  
Per original report from Robert Haas, with a patch based on a suggestion  
by Andres Freund.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : 85c809496d75361aae03d70c68c286f8e2255c68    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 May 2021 13:03:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 May 2021 13:03:09 -0400    

"typename" is a C++ keyword, so pg_upgrade.h fails to compile in C++.  
Fortunately, there seems no likely reason for somebody to need to  
do that.  Nonetheless, it's project policy that all .h files should  
pass cpluspluscheck, so rename the argument to fix that.  
  
Oversight in 57c081de0; back-patch as that was.  (The policy requiring  
pg_upgrade.h to pass cpluspluscheck only goes back to v12, but it  
seems best to keep this code looking the same in all branches.)  

commit   : 943bda157ecad3b08c875716b7def77443ec2151    
  
author   : David Rowley <[email protected]>    
date     : Tue, 18 May 2021 09:58:21 +1200    
  
committer: David Rowley <[email protected]>    
date     : Tue, 18 May 2021 09:58:21 +1200    

README.barrier didn't seem to get the memo when atomics were added. Fix  
that.  
  
Author: Tatsuo Ishii, David Rowley  
Discussion: https://postgr.es/m/20210516.211133.2159010194908437625.t-ishii%40sraoss.co.jp  
Backpatch-through: 9.6, oldest supported release  

commit   : 5d195dc40af07cc822a20fd8a9a9f9de2a1df43d    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 15 May 2021 12:21:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 15 May 2021 12:21:06 -0400    

ForgetBackgroundWorker lacked any memory barrier at all, while  
BackgroundWorkerStateChange had one but unaccountably did  
additional manipulation of the slot after the barrier.  AFAICS,  
the rule must be that the barrier is immediately before setting  
or clearing slot->in_use.  
  
It looks like back in 9.6 when ForgetBackgroundWorker was first  
written, there might have been some case for not needing a  
barrier there, but I'm not very convinced of that --- the fact  
that the load of bgw_notify_pid is in the caller doesn't seem  
to guarantee no memory ordering problem.  So patch 9.6 too.  
  
It's likely that this doesn't fix any observable bug on Intel  
hardware, but machines with weaker memory ordering rules could  
have problems here.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5015d3c35c6bc33924d8c05a71bf238a5bdb39c1    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 May 2021 15:07:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 May 2021 15:07:34 -0400    

Formerly we just relied on operator classes that assert longValuesOK  
to eventually shorten the leaf value enough to fit on an index page.  
That fails since the introduction of INCLUDE-column support (commit  
09c1c6ab4), because the INCLUDE columns might alone take up more  
than a page, meaning no amount of leaf-datum compaction will get  
the job done.  At least with spgtextproc.c, that leads to an infinite  
loop, since spgtextproc.c won't throw an error for not being able  
to shorten the leaf datum anymore.  
  
To fix without breaking cases that would otherwise work, add logic  
to spgdoinsert() to verify that the leaf tuple size is decreasing  
after each "choose" step.  Some opclasses might not decrease the  
size on every single cycle, and in any case, alignment roundoff  
of the tuple size could obscure small gains.  Therefore, allow  
up to 10 cycles without additional savings before throwing an  
error.  (Perhaps this number will need adjustment, but it seems  
quite generous right now.)  
  
As long as we've developed this logic, let's back-patch it.  
The back branches don't have INCLUDE columns to worry about, but  
this seems like a good defense against possible bugs in operator  
classes.  We already know that an infinite loop here is pretty  
unpleasant, so having a defense seems to outweigh the risk of  
breaking things.  (Note that spgtextproc.c is actually the only  
known opclass with longValuesOK support, so that this is all moot  
for known non-core opclasses anyway.)  
  
Per report from Dilip Kumar.  
  
Discussion: https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com  

commit   : 4c6cfcc377aaa945e3662319787e6767081e0f43    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 May 2021 13:26:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 May 2021 13:26:55 -0400    

Knowing that a buggy opclass could cause an infinite insertion loop,  
spgdoinsert() intended to allow its loop to be interrupted by query  
cancel.  However, that never actually worked, because in iterations  
after the first, we'd be holding buffer lock(s) which would cause  
InterruptHoldoffCount to be positive, preventing servicing of the  
interrupt.  
  
To fix, check if an interrupt is pending, and if so fall out of  
the insertion loop and service the interrupt after we've released  
the buffers.  If it was indeed a query cancel, that's the end of  
the matter.  If it was a non-canceling interrupt reason, make use  
of the existing provision to retry the whole insertion.  (This isn't  
as wasteful as it might seem, since any upper-level index tuples we  
already created should be usable in the next attempt.)  
  
While there's no known instance of such a bug in existing release  
branches, it still seems like a good idea to back-patch this to  
all supported branches, since the behavior is fairly nasty if a  
loop does happen --- not only is it uncancelable, but it will  
quickly consume memory to the point of an OOM failure.  In any  
case, this code is certainly not working as intended.  
  
Per report from Dilip Kumar.  
  
Discussion: https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com  

commit   : 567328989c19d1f9f657f5c1b1eac61b29e89b3a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 May 2021 12:54:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 May 2021 12:54:26 -0400    

Split up CHECK_FOR_INTERRUPTS() to provide an additional macro  
INTERRUPTS_PENDING_CONDITION(), which just tests whether an  
interrupt is pending without attempting to service it.  This is  
useful in situations where the caller knows that interrupts are  
blocked, and would like to find out if it's worth the trouble  
to unblock them.  
  
Also add INTERRUPTS_CAN_BE_PROCESSED(), which indicates whether  
CHECK_FOR_INTERRUPTS() can be relied on to clear the pending interrupt.  
  
This commit doesn't actually add any uses of the new macros,  
but a follow-on bug fix will do so.  Back-patch to all supported  
branches to provide infrastructure for that fix.  
  
Alvaro Herrera and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]