PostgreSQL 11.19 (upcoming) commit log

Fix binary mismatch for MSVC plperl vs gcc built perl libs

commit   : 724dd5649079a38193793c00292419917969effb    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 27 Nov 2022 09:03:22 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 27 Nov 2022 09:03:22 -0500    

Click here for diff

When loading plperl built against Strawberry perl or the msys2 ucrt perl  
that have been built with gcc, a binary mismatch has been encountered  
which looks like this:  
  
loadable library and perl binaries are mismatched (got handshake key 0000000012800080, needed 0000000012900080)  
  
To cure this we bring the handshake keys into sync by adding  
NO_THREAD_SAFE_LOCALE to the defines used to build plperl.  
  
Discussion: https://postgr.es/m/20211005004334.tgjmro4kuachwiuc@alap3.anarazel.de  
Discussion: https://postgr.es/m/c2da86a0-2906-744c-923d-16da6047875e@dunslane.net  
  
Backpatch to all live branches.  

M src/tools/msvc/Mkvcbuild.pm

Remove temporary portlock directory during make [dist]clean.

commit   : b85fd738529b345666c4a94ce837327a2f86d75e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Nov 2022 10:30:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Nov 2022 10:30:31 -0500    

Click here for diff

Another oversight in 9b4eafcaf.  

M GNUmakefile.in

Add portlock directory to .gitignore

commit   : 9d3f29d990f0dd404c5ec6406ef11e9c5fed901f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 26 Nov 2022 07:44:23 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 26 Nov 2022 07:44:23 -0500    

Click here for diff

Commit 9b4eafcaf4 added creattion of a directory to reserve TAP test  
ports at the top of the build tree. In a non-vpath build this means at  
the top of the source tree, so it needs to be added to .gitignore.  
  
As suggested by Michael Paquier  
  
Backpatch to all live branches.  

M .gitignore

Allow building with MSVC and Strawberry perl

commit   : ae7c5121307d5c8b92b4e0ac63ec2e8635d8c076    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 25 Nov 2022 15:28:38 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 25 Nov 2022 15:28:38 -0500    

Click here for diff

Strawberry uses __builtin_expect which Visual C doesn't have. For this  
case define it as a noop. Solution taken from vim sources.  
  
Backpatch to all live branches  

M src/pl/plperl/plperl.h

Fix uninitialized access to InitialRunningXacts during decoding.

commit   : 9b788aafdc64531388e0f2c0f064e946b8aa6378    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Nov 2022 08:56:54 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Nov 2022 08:56:54 +0530    

Click here for diff

In commit 272248a0c, we introduced an InitialRunningXacts array to  
remember transactions and subtransactions that were running when the  
xl_running_xacts record that we decoded was written. This array was  
allocated in the snapshot builder memory context after we restore  
serialized snapshot but we forgot to reset the array while freeing the  
builder memory context. So, the next time when we start decoding in the  
same session where we don't restore any serialized snapshot, we ended up  
using the uninitialized array and that can lead to unpredictable behavior.  
  
This problem doesn't exist in HEAD as instead of using  
InitialRunningXacts, we added the list of transaction IDs and  
sub-transaction IDs, that have modified catalogs and are running during  
snapshot serialization, to the serialized snapshot (see commit 7f13ac8123).  
  
Reported-by: Maxim Orlov  
Author: Masahiko Sawada  
Reviewed-by: Amit Kapila, Maxim Orlov  
Backpatch-through: 11  
Discussion: https://postgr.es/m/CACG=ezZoz_KG+Ryh9MrU_g5e0HiVoHocEvqFF=NRrhrwKmEQJQ@mail.gmail.com  

M src/backend/replication/logical/snapbuild.c

Make multixact error message more explicit

commit   : b20e381422089f66d2cfa7a6286c8053006d3afb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 24 Nov 2022 10:45:10 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 24 Nov 2022 10:45:10 +0100    

Click here for diff

There are recent reports involving a very old error message that we have  
no history of hitting -- perhaps a recently introduced bug.  Improve the  
error message in an attempt to improve our chances of investigating the  
bug.  
  
Per reports from Dimos Stamatakis and Bob Krier.  
  
Backpatch to 11.  
  
Discussion: https://postgr.es/m/CO2PR0801MB2310579F65529380A4E5EDC0E20A9@CO2PR0801MB2310.namprd08.prod.outlook.com  
Discussion: https://postgr.es/m/17518-04e368df5ad7f2ee@postgresql.org  

M src/backend/access/transam/multixact.c

Fix perl warning from commit 9b4eafcaf4

commit   : 2f92b8ad3121d9f23c48afbd3a60a2592cf90ba0    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 23 Nov 2022 07:17:26 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 23 Nov 2022 07:17:26 -0500    

Click here for diff

per gripe from Andres Freund and Tom Lane  
  
Backpatch to all live branches.  

M src/test/perl/PostgresNode.pm

YA attempt at taming worst-case behavior of get_actual_variable_range.

commit   : b96a096dbc2bdee3cce05f0230e87ae40c641491    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Nov 2022 14:40:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Nov 2022 14:40:20 -0500    

Click here for diff

We've made multiple attempts at preventing get_actual_variable_range  
from taking an unreasonable amount of time (3ca930fc3, fccebe421).  
But there's still an issue for the very first planning attempt after  
deletion of a large number of extremal-valued tuples.  While that  
planning attempt will set "killed" bits on the tuples it visits and  
thereby reduce effort for next time, there's still a lot of work it  
has to do to visit the heap and then set those bits.  It's (usually?)  
not worth it to do that much work at plan time to have a slightly  
better estimate, especially in a context like this where the table  
contents are known to be mutating rapidly.  
  
Therefore, let's bound the amount of work to be done by giving up  
after we've visited 100 heap pages.  Giving up just means we'll  
fall back on the extremal value recorded in pg_statistic, so it  
shouldn't mean that planner estimates suddenly become worthless.  
  
Note that this means we'll still gradually whittle down the problem  
by setting a few more index "killed" bits in each planning attempt;  
so eventually we'll reach a good state (barring further deletions),  
even in the absence of VACUUM.  
  
Simon Riggs, per a complaint from Jakub Wartak (with cosmetic  
adjustments by me).  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAKZiRmznOwi0oaV=4PHOCM4ygcH4MgSvt8=5cu_vNCfc8FSUug@mail.gmail.com  

M src/backend/utils/adt/selfuncs.c

Prevent port collisions between concurrent TAP tests

commit   : 46def5267cf938e6031d82aece2d50b3f6a17de4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 22 Nov 2022 10:35:04 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 22 Nov 2022 10:35:04 -0500    

Click here for diff

Currently there is a race condition where if concurrent TAP tests both  
test that they can open a port they will assume that it is free and use  
it, causing one of them to fail. To prevent this we record a reservation  
using an exclusive lock, and any TAP test that discovers a reservation  
checks to see if the reserving process is still alive, and looks for  
another free port if it is.  
  
Ports are reserved in a directory set by the environment setting  
PG_TEST_PORT_DIR, or if that doesn't exist a subdirectory of the top  
build directory as set by Makefile.global, or its own  
tmp_check directory.  
  
The prove_check recipe in Makefile.global.in is extended to export  
top_builddir to the TAP tests. This was already exported by the  
prove_installcheck recipes.  
  
Per complaint from Andres Freund  
  
Backpatched from 9b4eafcaf4 to all live branches  
  
Discussion: https://postgr.es/m/20221002164931.d57hlutrcz4d2zi7@awork3.anarazel.de  

M src/Makefile.global.in
M src/test/perl/PostgresNode.pm

doc: Fix description of pg_stat_all_tables.n_tup_upd

commit   : aa1fe772c9dbdf54bae6a3cbdb31625cb0579a9e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Nov 2022 09:16:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 22 Nov 2022 09:16:02 +0900    

Click here for diff

Issue caused by an incorrect merge done in f507895.  
  
This issue only impacts v11 and v12.  
  
Author: Guillaume Lelarge  
Discussion: https://postgr.es/m/CAECtzeUAL3qoebLBDnn2DfWYS0Kww-yqDicQQ3r+JS5Yu1n6FA@mail.gmail.com  
Backpatch-through: 11  

M doc/src/sgml/monitoring.sgml

commit   : 926ba562ef4f85e922aef6ee64a5209fe2d00d54    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 21 Nov 2022 23:25:48 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 21 Nov 2022 23:25:48 +0100    

Click here for diff

The Hunspell project moved from Sourceforge to Github sometime  
in 2016, so update our links to match the new URL.  Backpatch  
the doc changes to all supported versions.  
  
Discussion: https://postgr.es/m/DC9A662A-360D-4125-A453-5A6CB9C6C4B4@yesql.se  
Backpatch-through: v11  

M doc/src/sgml/textsearch.sgml

Add comments and a missing CHECK_FOR_INTERRUPTS in ts_headline.

commit   : c0eed88914c0986e0c64c9d0944c89e1c5bdb1e3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 17:07:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 17:07:07 -0500    

Click here for diff

I just spent an annoying amount of time reverse-engineering the  
100%-undocumented API between ts_headline and the text search  
parser's prsheadline function.  Add some commentary about that  
while it's fresh in mind.  Also remove some unused macros in  
wparser_def.c.  
  
While at it, I noticed that when commit 78e73e875 added a  
CHECK_FOR_INTERRUPTS call in TS_execute_recurse, it missed  
doing so in the parallel function TS_phrase_execute, which  
surely needs one just as much.  
  
Back-patch because of the missing CHECK_FOR_INTERRUPTS.  
Might as well back-patch the rest of this too.  

M src/backend/tsearch/ts_parse.c
M src/backend/tsearch/wparser_def.c
M src/backend/utils/adt/tsvector_op.c
M src/include/tsearch/ts_public.h

commit   : 140c80372327fb7723859d982b3efda754b266a7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 16 Nov 2022 20:00:59 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 16 Nov 2022 20:00:59 -0800    

Click here for diff

ProcSleep() used a PGPROC* variable to point to PROC_QUEUE->links.next,  
because that does "the right thing" with SHMQueueInsertBefore(). While that  
largely works, it's certainly not correct and unnecessary - we can just use  
SHM_QUEUE* to point to the insertion point.  
  
Noticed when testing a 32bit of postgres with undefined behavior  
sanitizer. UBSan noticed that sometimes the supposed PGPROC wasn't  
sufficiently aligned (required since 46d6e5f5679, ensured indirectly, via  
ShmemAllocRaw() guaranteeing cacheline alignment).  
  
For now fix this by using a SHM_QUEUE* for the insertion point. Subsequently  
we should replace all the use of PROC_QUEUE and SHM_QUEUE with ilist.h, but  
that's a larger change that we don't want to backpatch.  
  
Backpatch to all supported versions - it's useful to be able to run postgres  
under UBSan.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20221117014230.op5kmgypdv2dtqsf@awork3.anarazel.de  
Backpatch: 11-  

M src/backend/storage/lmgr/proc.c

Doc: sync src/tutorial/basics.source with SGML documentation.

commit   : 8687cee44d003acaeb2bca908275d04092741e88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 13:09:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 13:09:14 -0500    

Click here for diff

basics.source is supposed to be pretty closely in step with  
the examples in chapter 2 of the tutorial, but I forgot to  
update it in commit f05a5e000.  Fix that, and adjust a couple  
of other discrepancies that had crept in over time.  
  
(I notice that advanced.source is nowhere near being in sync  
with chapter 3, but I lack the ambition to do something  
about that right now.)  

M src/tutorial/basics.source

pg_dump: avoid unsafe function calls in getPolicies().

commit   : b7333e826955092776108dfdb7cd358beeeca138    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 12:00:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 12:00:27 -0500    

Click here for diff

getPolicies() had the same disease I fixed in other places in  
commit e3fcbbd62, i.e., it was calling pg_get_expr() for  
expressions on tables that we don't necessarily have lock on.  
To fix, restrict the query to only collect interesting rows,  
rather than doing the filtering on the client side.  
  
Back-patch of commit 3e6e86abc.  That's been in v15/HEAD long enough  
to have some confidence about it, so now let's fix the problem in  
older branches.  
  
Discussion: https://postgr.es/m/2273648.1634764485@sss.pgh.pa.us  
Discussion: https://postgr.es/m/7d7eb6128f40401d81b3b7a898b6b4de@W2012-02.nidsa.loc  
Discussion: https://postgr.es/m/45c93d57-9973-248e-d2df-e02ca9af48d4@darold.net  

M src/bin/pg_dump/pg_dump.c

Postpone calls of unsafe server-side functions in pg_dump.

commit   : b1f106420b1a1703a1703fdf90bcdd703f322cd1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 11:40:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 11:40:30 -0500    

Click here for diff

Avoid calling pg_get_partkeydef(), pg_get_expr(relpartbound),  
and regtypeout until we have lock on the relevant tables.  
The existing coding is at serious risk of failure if there  
are any concurrent DROP TABLE commands going on --- including  
drops of other sessions' temp tables.  
  
Back-patch of commit e3fcbbd62.  That's been in v15/HEAD long enough  
to have some confidence about it, so now let's fix the problem in  
older branches.  
  
Original patch by me; thanks to Gilles Darold for back-patching  
legwork.  
  
Discussion: https://postgr.es/m/2273648.1634764485@sss.pgh.pa.us  
Discussion: https://postgr.es/m/7d7eb6128f40401d81b3b7a898b6b4de@W2012-02.nidsa.loc  
Discussion: https://postgr.es/m/45c93d57-9973-248e-d2df-e02ca9af48d4@darold.net  

M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h

Replace RelationOpenSmgr() with RelationGetSmgr().

commit   : d4acf2eb94f3464d5f439ca83a4188496cd5841a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Nov 2022 16:54:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Nov 2022 16:54:31 -0500    

Click here for diff

This is a back-patch of the v15-era commit f10f0ae42 into older  
supported branches.  The idea is to design out bugs in which an  
ill-timed relcache flush clears rel->rd_smgr partway through  
some code sequence that wasn't expecting that.  We had another  
report today of a corner case that reliably crashes v14 under  
debug_discard_caches (nee CLOBBER_CACHE_ALWAYS), and therefore  
would crash once in a blue moon in the field.  We're unlikely  
to get rid of all such code paths unless we adopt the more  
rigorous coding rules instituted by f10f0ae42.  Therefore,  
even though this is a bit invasive, it's time to back-patch.  
Some comfort can be taken in the fact that f10f0ae42 has been  
in v15 for 16 months without problems.  
  
I left the RelationOpenSmgr macro present in the back branches,  
even though no core code should use it anymore, in order to not break  
third-party extensions in minor releases.  Such extensions might opt  
to start using RelationGetSmgr instead, to reduce their code  
differential between v15 and earlier branches.  This carries a hazard  
of failing to compile against headers from existing minor releases.  
However, once compiled the extension should work fine even with such  
releases, because RelationGetSmgr is a "static inline" function so  
it creates no link-time dependency.  So depending on distribution  
practices, that might be an OK tradeoff.  
  
Per report from Spyridon Dimitrios Agathos.  Original patch  
by Amul Sul.  
  
Discussion: https://postgr.es/m/CAFM5RaqdgyusQvmWkyPYaWMwoK5gigdtW-7HcgHgOeAw7mqJ_Q@mail.gmail.com  
Discussion: https://postgr.es/m/CANiYTQsU7yMFpQYnv=BrcRVqK_3U3mtAzAsJCaqtzsDHfsUbdQ@mail.gmail.com  

M contrib/amcheck/verify_nbtree.c
M contrib/bloom/blinsert.c
M contrib/pg_prewarm/autoprewarm.c
M contrib/pg_prewarm/pg_prewarm.c
M contrib/pg_visibility/pg_visibility.c
M src/backend/access/gist/gistbuild.c
M src/backend/access/hash/hashpage.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/rewriteheap.c
M src/backend/access/heap/visibilitymap.c
M src/backend/access/nbtree/nbtree.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/spgist/spginsert.c
M src/backend/catalog/heap.c
M src/backend/catalog/index.c
M src/backend/catalog/storage.c
M src/backend/commands/tablecmds.c
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/freespace/freespace.c
M src/include/utils/rel.h

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

commit   : 791dd7579149a6a393a43935f976c19039360f94    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 17 Nov 2022 07:35:06 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
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: https://postgr.es/m/20221117061805.GA4020280@rfd.leadboat.com  

M src/test/perl/TestLib.pm

Fix cleanup lock acquisition in SPLIT_ALLOCATE_PAGE replay.

commit   : 1703033f896a7825001d8b1e17fa24613408d852    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 14 Nov 2022 09:52:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 14 Nov 2022 09:52:06 +0530    

Click here for diff

During XLOG_HASH_SPLIT_ALLOCATE_PAGE replay, we were checking for a  
cleanup lock on the new bucket page after acquiring an exclusive lock on  
it and raising a PANIC error on failure. However, it is quite possible  
that checkpointer can acquire the pin on the same page before acquiring a  
lock on it, and then the replay will lead to an error. So instead, directly  
acquire the cleanup lock on the new bucket page during  
XLOG_HASH_SPLIT_ALLOCATE_PAGE replay operation.  
  
Reported-by: Andres Freund  
Author: Robert Haas  
Reviewed-By: Amit Kapila, Andres Freund, Vignesh C  
Backpatch-through: 11  
Discussion: https://postgr.es/m/20220810022617.fvjkjiauaykwrbse@awork3.anarazel.de  

M src/backend/access/hash/hash_xlog.c
M src/backend/access/hash/hashpage.c

Fix theoretical torn page hazard.

commit   : 5eaf3e375dc77a254efa098bdb1413bbd0ef9f1a    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 10 Nov 2022 14:46:30 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 10 Nov 2022 14:46:30 -0800    

Click here for diff

The original report was concerned with a possible inconsistency  
between the heap and the visibility map, which I was unable to  
confirm. The concern has been retracted.  
  
However, there did seem to be a torn page hazard when using  
checksums. By not setting the heap page LSN during redo, the  
protections of minRecoveryPoint were bypassed. Fixed, along with a  
misleading comment.  
  
It may have been impossible to hit this problem in practice, because  
it would require a page tear between the checksum and the flags, so I  
am marking this as a theoretical risk. But, as discussed, it did  
violate expectations about the page LSN, so it may have other  
consequences.  
  
Backpatch to all supported versions.  
  
Reported-by: Konstantin Knizhnik  
Reviewed-by: Konstantin Knizhnik  
Discussion: https://postgr.es/m/fed17dac-8cb8-4f5b-d462-1bb4908c029e@garret.ru  
Backpatch-through: 11  

M src/backend/access/heap/heapam.c

Fix alter_table.sql test case to test what it claims to.

commit   : 421f3363a8c1035cfc2e0684bf8b24df2afe2902    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Nov 2022 17:24:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Nov 2022 17:24:26 -0500    

Click here for diff

The stanza "SET STORAGE may need to add a TOAST table" does not  
test what it's supposed to, and hasn't done so since we added  
the ability to store constant column default values as metadata.  
We need to use a non-constant default to get the expected table  
rewrite to actually happen.  
  
Fix that, and add the missing checks that would have exposed the  
problem to begin with.  
  
Noted while reviewing a patch that made changes in this test case.  
Back-patch to v11 where the problem came in.  

M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql

Doc: add comments about PreventInTransactionBlock/IsInTransactionBlock.

commit   : fec80da849f3374c2931cc3bf593edca15041ece    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Nov 2022 11:08:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Nov 2022 11:08:52 -0500    

Click here for diff

Add a little to the header comments for these functions to make it  
clearer what guarantees about commit behavior are provided to callers.  
(See commit f92944137 for context.)  
  
Although this is only a comment change, it's really documentation  
aimed at authors of extensions, so it seems appropriate to back-patch.  
  
Yugo Nagata and Tom Lane, per further discussion of bug #17434.  
  
Discussion: https://postgr.es/m/17434-d9f7a064ce2a88a3@postgresql.org  

M src/backend/access/transam/xact.c

Fix compilation warnings with libselinux 3.1 in contrib/sepgsql/

commit   : 91723759e450adff35664926a0328fb8a2c02cf4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Nov 2022 09:39:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Nov 2022 09:39:57 +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: https://postgr.es/m/20200813012735.GC11663@paquier.xyz  
Discussion: https://postgr.es/m/20221103181028.raqta27jcuypor4l@alvherre.pgsql  
Backpatch-through: 9.2  

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

Doc: improve tutorial section about grouped aggregates.

commit   : 679c394f538729f7d84d01f7afc0e1239f818361    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Nov 2022 18:25:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Nov 2022 18:25:03 -0500    

Click here for diff

Commit fede15417 introduced FILTER by jamming it into the existing  
example introducing HAVING, which seems pedagogically poor to me;  
and it added no information about what the keyword actually does.  
Not to mention that the claimed output didn't match the sample  
data being used in this running example.  
  
Revert that and instead make an independent example using FILTER.  
To help drive home the point that it's a per-aggregate filter,  
we need to use two aggregates not just one; for consistency  
expand all the examples in this segment to do that.  
  
Also adjust the example using WHERE ... LIKE so that it'd produce  
nonempty output with this sample data, and show that output.  
  
Back-patch, as the previous patch was.  (Sadly, v10 is now out  
of scope.)  
  
Discussion: https://postgr.es/m/166794307526.652.9073408178177444190@wrigleys.postgresql.org  

M doc/src/sgml/query.sgml