PostgreSQL 9.3.26 (not released) commit log

commit   : 524440579f838b30579f35d2045cc01b6f5070d8    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 5 Feb 2019 15:16:55 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 5 Feb 2019 15:16:55 -0500    

It doesn't like code before "use strict;".  
  
(cherry picked from commit ed2c2d063bd110f299211611b72a5dbe07a4d7be)  

commit   : 96feeab4b3a91e1d544950e3c2d7804287e148af    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 5 Feb 2019 09:59:46 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 5 Feb 2019 09:59:46 -0500    

This was fixed for MSVC tools by commit 1df92eeafefac4, but per  
buildfarm member bowerbird genbki.pl needs the same treatment.  
  
Backpatch to all live branches.  
  
(cherry picked from commit 51884fa16a179852ec851172a72588d8e84ec05e)  

commit   : 2e8bedc3d68c362a723dbbd94a30665cf411e013    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 16 Jan 2023 20:35:53 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 16 Jan 2023 20:35:53 -0500    

To test pg_upgrade across major PG versions, we have to be able to  
modify or drop any old objects with no-longer-supported properties,  
and we have to be able to deal with cosmetic changes in pg_dump output.  
Up to now, the buildfarm and pg_upgrade's own test infrastructure had  
separate implementations of the former, and we had nothing but very  
ad-hoc rules for the latter (including an arbitrary threshold on how  
many lines of unchecked diff were okay!).  This patch creates a Perl  
module that can be shared by both those use-cases, and adds logic  
that deals with pg_dump output diffs in a much more tightly defined  
fashion.  
  
This largely supersedes previous efforts in commits 0df9641d3,  
9814ff550, and 62be9e4cd, which developed a SQL-script-based solution  
for the task of dropping old objects.  There was nothing fundamentally  
wrong with that work in itself, but it had no basis for solving the  
output-formatting problem.  The most plausible way to deal with  
formatting is to build a Perl module that can perform editing on the  
dump files; and once we commit to that, it makes more sense for the  
same module to also embed the knowledge of what has to be done for  
dropping old objects.  
  
Back-patch versions of the helper module as far as 9.2, to  
support buildfarm animals that still test that far back.  
It's also necessary to back-patch PostgreSQL/Version.pm,  
because the new code depends on that.  I fixed up pg_upgrade's  
002_pg_upgrade.pl in v15, but did not look into back-patching  
it further than that.  
  
Tom Lane and Andrew Dunstan  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a5171b8800f10694f22f2665cc881424a6b2bd72    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 9 Nov 2022 09:40:06 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 9 Nov 2022 09:40:06 +0900    

Upstream SELinux has recently marked security_context_t as officially  
deprecated, causing warnings with -Wdeprecated-declarations.  This is  
considered as legacy code for some time now by upstream as  
security_context_t got removed from most of the code tree during the  
development of 2.3 back in 2014.  
  
This removes all the references to security_context_t in sepgsql/ to be  
consistent with SELinux, fixing the warnings.  Note that this does not  
impact the minimum version of libselinux supported.  
  
This has been applied first as 1f32136 for 14~, but no other branches  
got the call.  This is in line with the recent project policy to have no  
warnings in branches where builds should still be supported (9.2~ as of  
today).  Per discussion with Tom Lane and Álvaro Herrera.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.2  

commit   : ee4c44014400a79a69e094f60d39b1fdcd599998    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 16 Oct 2022 15:27:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 16 Oct 2022 15:27:04 -0400    

In the latest version of Apple's macOS SDK, <sys/socket.h>  
fails to compile if "REF" is #define'd as something.  
Apple may or may not agree that this is a bug, and even if  
they do accept the bug report I filed, they probably won't  
fix it very quickly.  In the meantime, our back branches will all  
fail to compile gram.y.  v15 and HEAD currently escape the problem  
thanks to the refactoring done in 98e93a1fc, but that's purely  
accidental.  Moreover, since that patch removed a widely-visible  
inclusion of <netdb.h>, back-patching it seems too likely to break  
third-party code.  
  
Instead, change the token's code name to REF_P, following our usual  
convention for naming parser tokens that are likely to have symbol  
conflicts.  The effects of that should be localized to the grammar  
and immediately surrounding files, so it seems like a safer answer.  
  
Per project policy that we want to keep recently-out-of-support  
branches buildable on modern systems, back-patch all the way to 9.2.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f6ce9cee620702d8df551cd25761169f45503dc9    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 21 Sep 2022 15:42:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 21 Sep 2022 15:42:00 -0400    

Back-port commit 16fbac39f into 9.3 and 9.2, so that these  
out-of-support branches can be built with clang without wading  
through a pile of warnings about strlcpy and related functions.  
check_decls.m4 required some adaptation to work with autoconf 2.63,  
but nothing too major.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : bf216123446c4aa81998f51e54e55ae706ff175e    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 21 Sep 2022 13:52:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 21 Sep 2022 13:52:38 -0400    

Mop up assorted set-but-not-used warnings in the back branches.  
This includes back-patching relevant fixes from commit 152c9f7b8  
the rest of the way, but there are also several cases that did not  
appear in HEAD.  Some of those we'd fixed in a retail way but not  
back-patched, and others I think just got rewritten out of existence  
during nearby refactoring.  
  
While here, also back-patch b1980f6d0 (PL/Tcl: Fix compiler warnings  
with Tcl 8.6) into 9.2, so that that branch compiles warning-free  
with modern Tcl.  
  
Per project policy, this is a candidate for back-patching into  
out-of-support branches: it suppresses annoying compiler warnings  
but changes no behavior.  Hence, back-patch all the way to 9.2.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8c8ee5c991447528687356ac570bf4190ef294ac    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 20 Sep 2022 18:59:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 20 Sep 2022 18:59:54 -0400    

There doesn't seem to be any good ABI-preserving way to silence  
clang 15's -Wdeprecated-non-prototype warnings about our tree-walk  
APIs.  While we've fixed it properly in HEAD, the only way to not  
see hundreds of these in the back branches is to disable the  
warnings.  We're not going to do anything about them, so we might  
as well disable them.  
  
I noticed that we also get some of these warnings about fmgr.c's  
support for V0 function call convention, in branches before v10  
where we removed that.  That's another area we aren't going to  
change, so turning off the warning seems fine for that too.  
  
Per project policy, this is a candidate for back-patching into  
out-of-support branches: it suppresses annoying compiler warnings  
but changes no behavior.  Hence, back-patch all the way to 9.2.  
  
Discussion: https://postgr.es/m/CA+hUKGKpHPDTv67Y+s6yiC8KH5OXeDg6a-twWo_xznKTcG0kSA@mail.gmail.com  

commit   : a3b685fdd13e99f4fe35c4e932d7177ee1b3e703    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 1 Jun 2022 16:15:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 1 Jun 2022 16:15:47 -0400    

Perl 5.36 has reclassified the warning condition that this test  
case used, so that the expected error fails to appear.  Tweak  
the test so it instead exercises a case that's handled the same  
way in all Perl versions of interest.  
  
This appears to meet our standards for back-patching into  
out-of-support branches: it changes no user-visible behavior  
but enables testing of old branches with newer tools.  
Hence, back-patch as far as 9.2.  
  
Dagfinn Ilmari Mannsåker, per report from Jitka Plesníková.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f70550327ba53c052f4c8171044c7d23edacc79c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 23 Jan 2022 11:09:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 23 Jan 2022 11:09:00 -0500    

In the normal configuration where GEQO_DEBUG isn't defined,  
recent clang versions have started to complain that geqo_main.c  
accumulates the edge_failures count but never does anything  
with it.  As a minimal back-patchable fix, insert a void cast  
to silence this warning.  (I'd speculated about ripping out the  
GEQO_DEBUG logic altogether, but I don't think we'd wish to  
back-patch that.)  
  
Per recently-established project policy, this is a candidate  
for back-patching into out-of-support branches: it suppresses  
an annoying compiler warning but changes no behavior.  Hence,  
back-patch all the way to 9.2.  
  
Discussion: https://postgr.es/m/CA+hUKGLTSZQwES8VNPmWO9AO0wSeLt36OCPDAZTccT1h7Q7kTQ@mail.gmail.com  

commit   : 020bfc84190966cc37a7980c1017d3956a0a4b15    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 15 Dec 2021 17:57:10 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 15 Dec 2021 17:57:10 -0500    

This will enable things like the buildfarm client to discover more  
reliably if certain libraries have been installed.  
  
Discussion: https://postgr.es/m/[email protected]  
  
This is a backpatch to 9.3 and 9.2 of commits b40cb99b85 and d9cdb1ba9e  
now that we are supporting limited builds of older versions.  

commit   : fcf1f27fe89bb017e5f05cc79bd640b96c6f7ba9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Dec 2021 00:24:38 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Dec 2021 00:24:38 -0500    

With some newer gcc versions (8 and 9) you get a -Wformat-overflow  
warning here.  In PG11 and later this was already fixed.  Since it's  
trivial, backport it to get the older branches building without  
warnings.  
  
This back-patches commit 333a186dc into out-of-support branches,  
pursuant to newly-established project policy.  The point is to  
suppress scary-looking warnings so that people building these  
branches needn't expend brain cells verifying that it's safe  
to ignore the warnings.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a1fe82d98745483b250ab61c3bc903931dc966ba    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Dec 2021 00:08:33 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Dec 2021 00:08:33 -0500    

Per buildfarm and local experimentation, bleeding-edge gcc isn't  
convinced that the MemSet in reorder_function_arguments() is safe.  
Shut it up by adding an explicit check that pronargs isn't negative,  
and by changing MemSet to memset.  (It appears that either change is  
enough to quiet the warning at -O2, but let's do both to be sure.)  
  
This back-patches commit 1046dbedd into out-of-support branches,  
pursuant to newly-established project policy.  The point is to  
suppress scary-looking warnings so that people building these  
branches needn't expend brain cells verifying that it's safe  
to ignore the warnings.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6eb7efdf0f7459e6f9889020da8a0df58c960bf3    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 20:24:50 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 20:24:50 -0500    

This is exactly the same problem as commit 1b242f42b fixed in ecpg,  
but in contrib/pgcrypto.  Commit 273c458a2 eliminated the problem  
here for v10 and up.  We hadn't noticed for exactly the same reasons  
enumerated in bbbf22cf3.  
  
Back-patch down to 9.2, pursuant to newly-established project policy  
about keeping out-of-support branches buildable.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9610c7158409d06e357e9c6c78b827c3f1c0626a    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 19:12:23 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 19:12:23 -0500    

Recent versions of gcc whine about the admittedly-completely-illegible  
formatting of this macro.  We've not noticed for a few reasons:  
  
* In v12 and up, the problem is gone thanks to 48e24ba6b.  
(Back-patching that doesn't seem prudent, though, so this patch  
just manually improves the macro's formatting.)  
  
* Buildfarm animals that might have complained, such as caiman,  
do not because they use --with-openssl and so don't build imath.c.  
  
* In a manual run such as "make all check-world", you won't see the  
warning because it gets buried in an install.log file.  You have to  
do "make -C contrib all" or the like to see it.  
  
I noticed this because in older branches, the last bit doesn't  
happen so "check-world" actually does spew the warnings to stderr.  
Maybe we should rethink how that works, because the newer behavior  
is not an improvement IMO.  
  
Back-patch down to 9.2, pursuant to newly-established project policy  
about keeping out-of-support branches buildable.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 580261836c115c13aa9eaeb4411f887138cedec4    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 18:06:11 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 18:06:11 -0500    

clang-12 has introduced -Wcompound-token-split-by-macro, that is causing  
a large amount of warnings when building PL/Perl because of its  
interactions with upstream Perl.  This commit adds one -Wno to CFLAGS at  
./configure time if the flag is supported by the compiler to silence all  
those warnings.  
  
This back-patches commit 9ff47ea41 into out-of-support branches,  
pursuant to newly-established project policy.  The point is to  
suppress scary-looking warnings so that people building these  
branches needn't expend brain cells verifying that it's safe  
to ignore the warnings.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b30e23fe588be6dd61be07eeac96adfbddfcc54c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 16:59:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 16:59:17 -0500    

We had "short *mdy" in the extern declarations, but "short mdy[3]"  
in the actual function definitions.  Per C99 these are equivalent,  
but recent versions of gcc have started to issue warnings about  
the inconsistency.  Clean it up before the warnings get any more  
widespread.  
  
This back-patches commit 1b242f42b into out-of-support branches,  
pursuant to newly-established project policy.  The point is to  
suppress scary-looking warnings so that people building these  
branches needn't expend brain cells verifying that it's safe  
to ignore the warnings.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 119b9d060e8fde2ede980e1e6d643b893f550399    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 16:14:22 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 16:14:22 -0500    

Remove "set -x", and pass "-A trust" to initdb explicitly,  
to suppress almost all of the noise this script used to emit  
on stderr.  
  
This back-patches commit eb9812f27 into out-of-support branches,  
pursuant to newly-established project policy.  The point is to  
suppress useless noise on stderr when running check-world.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 404d987646e395b893fbaae17525e1ce45c75c80    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 15:58:57 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 15:58:57 -0500    

This back-patches commit d9f37e666 into out-of-support branches,  
pursuant to newly-established project policy.  The point is to  
suppress "uninitialized variable" warnings so that people building  
these branches needn't expend brain cells verifying that it's safe  
to ignore the warnings.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f24374bce687a2279f9befd3a1da72bd9ca7d1bd    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 14:54:32 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 14:54:32 -0500    

Using exit() requires stdlib.h, which is not included.  Use return  
instead.  Also add return type for main().  
  
This back-patches commit 1c0cf52b3 into out-of-support branches,  
pursuant to a newly-established project policy that we'll try to keep  
out-of-support branches buildable on modern platforms for at least  
ten major releases back, ensuring people can test pg_dump and psql  
compatibility against servers that far back.  With the current  
development branch being v15, that works out to keeping 9.2 and up  
buildable as of today.  
  
This fix is needed to get through 'configure' when using recent  
macOS (and possibly other clang-based toolchains).  It seems to  
be sufficient to get through 'check-world', although there are  
annoyances such as compiler warnings, which will be dealt with  
separately.  
  
Original patch by Peter Eisentraut  
  
Discussion: https://postgr.es/m/[email protected]