PostgreSQL 10.24 (not released) commit log should zap test_ext_cine, too.

commit   : c18c12c983a84d55e58b176969782c7ffac3272b    
author   : Tom Lane <[email protected]>    
date     : Tue, 17 Jan 2023 16:00:39 -0500    
committer: Tom Lane <[email protected]>    
date     : Tue, 17 Jan 2023 16:00:39 -0500    

Click here for diff

test_extensions' test_ext_cine extension has the same upgrade hazard  
as test_ext7: the regression test leaves it in an updated state  
from which no downgrade path to default is provided.  This causes  
the update_extensions.sql script helpfully provided by pg_upgrade  
to fail.  So drop it in cross-version-upgrade testing.  
Not entirely sure how come I didn't hit this in testing yesterday;  
possibly I'd built the upgrade reference databases with  
testmodules-install-check disabled.  
Backpatch to v10 where this module was introduced.  

M src/test/perl/PostgreSQL/Test/

Create common infrastructure for cross-version upgrade testing.

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

Click here for diff

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  
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/,  
because the new code depends on that.  I fixed up pg_upgrade's in v15, but did not look into back-patching  
it further than that.  
Tom Lane and Andrew Dunstan  
Discussion:[email protected]  

D src/bin/pg_upgrade/upgrade_adapt.sql
A src/test/perl/PostgreSQL/Test/
A src/test/perl/PostgreSQL/

Account for IPC::Run::result() Windows behavior change.

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

Click here for diff

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:[email protected]  

M src/test/perl/

Fix compilation warnings with libselinux 3.1 in contrib/sepgsql/

commit   : 8f5d4ee6c5a1de2601934139c974bc09bc42edab    
author   : Michael Paquier <[email protected]>    
date     : Wed, 9 Nov 2022 09:39:58 +0900    
committer: Michael Paquier <[email protected]>    
date     : Wed, 9 Nov 2022 09:39:58 +0900    

Click here for diff

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:[email protected]  
Discussion:[email protected]  
Backpatch-through: 9.2  

M contrib/sepgsql/label.c
M contrib/sepgsql/selinux.c
M contrib/sepgsql/uavc.c