Create common infrastructure for cross-version upgrade testing.
commit : 3911fd55f53a930fcca6bc4889209021cc50ec2f
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] A src/test/perl/PostgreSQL/Test/AdjustUpgrade.pm
A src/test/perl/PostgreSQL/Version.pm
Account for IPC::Run::result() Windows behavior change.
commit : 7298b904b88598cee50e1b7649ba530811040706
author : Noah Misch <[email protected]>
date : Thu, 17 Nov 2022 07:35:06 -0800
committer: Noah Misch <[email protected]>
date : Thu, 17 Nov 2022 07:35:06 -0800 This restores compatibility with the not-yet-released successor of
version 20220807.0. Back-patch to 9.4, which introduced this code.
Reviewed by Andrew Dunstan.
Discussion: https://postgr.es/m/[email protected] M src/test/perl/TestLib.pm
Fix compilation warnings with libselinux 3.1 in contrib/sepgsql/
commit : b2b9881109def2be4b162149bf67dad8def53869
author : Michael Paquier <[email protected]>
date : Wed, 9 Nov 2022 09:40:01 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 9 Nov 2022 09:40:01 +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 M contrib/sepgsql/label.c
M contrib/sepgsql/selinux.c
M contrib/sepgsql/uavc.c
Rename parser token REF to REF_P to avoid a symbol conflict.
commit : 9bfa043a1379b121fc4ee58dcf2606e151b11b9d
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] M src/backend/parser/gram.y
M src/include/parser/kwlist.h
Suppress more variable-set-but-not-used warnings from clang 15.
commit : c705646b751e08d584f6eeb098f1ed002aa7b11c
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] M src/backend/optimizer/util/var.c
M src/backend/utils/adt/varlena.c
Disable -Wdeprecated-non-prototype in the back branches.
commit : ca8fd341e165e1b3f99deb07889aa58db7f8a898
author : Tom Lane <[email protected]>
date : Tue, 20 Sep 2022 18:59:53 -0400
committer: Tom Lane <[email protected]>
date : Tue, 20 Sep 2022 18:59:53 -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 M configure
M configure.in
Suppress variable-set-but-not-used warnings from clang 15.
commit : 85c077f9e0229d5e626f66d1a10e17a95c3564ff
author : Tom Lane <[email protected]>
date : Tue, 20 Sep 2022 12:04:37 -0400
committer: Tom Lane <[email protected]>
date : Tue, 20 Sep 2022 12:04:37 -0400 clang 15+ will issue a set-but-not-used warning when the only
use of a variable is in autoincrements (e.g., "foo++;").
That's perfectly sensible, but it detects a few more cases that
we'd not noticed before. Silence the warnings with our usual
methods, such as PG_USED_FOR_ASSERTS_ONLY, or in one case by
actually removing a useless variable.
One thing that we can't nicely get rid of is that with %pure-parser,
Bison emits "yynerrs" as a local variable that falls foul of this
warning. To silence those, I inserted "(void) yynerrs;" in the
top-level productions of affected grammars.
Per recently-established 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 to 9.5, which is as far as these patches go without
issues. (A preliminary check shows that the prior branches
need some other set-but-not-used cleanups too, so I'll leave
them for another day.)
Discussion: https://postgr.es/m/[email protected] M src/backend/access/gist/gistxlog.c
M src/backend/access/transam/xlog.c
M src/backend/parser/gram.y
M src/backend/utils/adt/array_typanalyze.c
M src/bin/pgbench/exprparse.y
Fix pl/perl test case so it will still work under Perl 5.36.
commit : d4c16184212a3a99be0b27975133df25a4adf2c0
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] M src/pl/plperl/expected/plperl.out
M src/pl/plperl/sql/plperl.sql
Use gendef instead of pexports for building windows .def files
commit : 622ab6a34f968610acfbc21d295530d2c5c83ac7
author : Andrew Dunstan <[email protected]>
date : Thu, 10 Feb 2022 13:44:05 -0500
committer: Andrew Dunstan <[email protected]>
date : Thu, 10 Feb 2022 13:44:05 -0500 Modern msys systems lack pexports but have gendef instead, so use that.
Discussion: https://postgr.es/m/[email protected]
Backpatch to release 9.4 to enable building with perl on older branches.
Before that pexports is not used for plperl. M src/pl/plperl/GNUmakefile
M src/pl/plpython/Makefile
M src/pl/tcl/Makefile
Suppress variable-set-but-not-used warning from clang 13.
commit : f3653d7992358708baf401fcabb239b46d27942f
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 M src/backend/optimizer/geqo/geqo_main.c
Suppress -Warray-parameter warnings in pgcrypto/sha2.c.
commit : 116a509e09acf80793eae148ce5f8392ae954b89
author : Tom Lane <[email protected]>
date : Sun, 12 Dec 2021 20:24:38 -0500
committer: Tom Lane <[email protected]>
date : Sun, 12 Dec 2021 20:24:38 -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] M contrib/pgcrypto/sha2.c
Reformat imath.c macro to remove -Wmisleading-indentation warnings.
commit : f420f24c0a5dee7ef35990d9a9dde4397b5d8ce7
author : Tom Lane <[email protected]>
date : Sun, 12 Dec 2021 19:12:09 -0500
committer: Tom Lane <[email protected]>
date : Sun, 12 Dec 2021 19:12:09 -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] M contrib/pgcrypto/imath.c
Clean up compilation warnings coming from PL/Perl with clang-12~
commit : c16a78147ca104602d18c8cc19ff3ed98606717c
author : Tom Lane <[email protected]>
date : Sun, 12 Dec 2021 18:05:59 -0500
committer: Tom Lane <[email protected]>
date : Sun, 12 Dec 2021 18:05:59 -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] M configure
M configure.in