Ignore dropped columns during apply of update/delete.
commit : 751d6676daf3413f7c0fbc83860238d02114dbcd
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Mar 2023 09:07:37 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Mar 2023 09:07:37 +0530
We fail to apply updates and deletes when the REPLICA IDENTITY FULL is
used for the table having dropped columns. We didn't use to ignore dropped
columns while doing tuple comparison among the tuples from the publisher
and subscriber during apply of updates and deletes.
Author: Onder Kalaci, Shi yu
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/CACawEhVQC9WoofunvXg12aXtbqKnEgWxoRx3+v8q32AWYsdpGg@mail.gmail.com
M src/backend/executor/execReplication.c
M src/test/subscription/t/100_bugs.pl
Fix race in parallel hash join batch cleanup, take II.
commit : 6e94d62e3f04b03c95bd707e43ba32147d35908e
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 21 Mar 2023 14:29:34 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 21 Mar 2023 14:29:34 +1300
With unlucky timing and parallel_leader_participation=off (not the
default), PHJ could attempt to access per-batch shared state just as it
was being freed. There was code intended to prevent that by checking
for a cleared pointer, but it was racy. Fix, by introducing an extra
barrier phase. The new phase PHJ_BUILD_RUNNING means that it's safe to
access the per-batch state to find a batch to help with, and
PHJ_BUILD_DONE means that it is too late. The last to detach will free
the array of per-batch state as before, but now it will also atomically
advance the phase, so that late attachers can avoid the hazard. This
mirrors the way per-batch hash tables are freed (see phases
PHJ_BATCH_PROBING and PHJ_BATCH_DONE).
An earlier attempt to fix this (commit 3b8981b6, later reverted) missed
one special case. When the inner side is empty (the "empty inner
optimization), the build barrier would only make it to
PHJ_BUILD_HASHING_INNER phase before workers attempted to detach from
the hashtable. In that case, fast-forward the build barrier to
PHJ_BUILD_RUNNING before proceeding, so that our later assertions hold
and we can still negotiate who is cleaning up.
Revealed by build farm failures, where BarrierAttach() failed a sanity
check assertion, because the memory had been clobbered by dsa_free().
In non-assert builds, the result could be a segmentation fault.
Back-patch to all supported releases.
Author: Thomas Munro <thomas.munro@gmail.com>
Author: Melanie Plageman <melanieplageman@gmail.com>
Reported-by: Michael Paquier <michael@paquier.xyz>
Reported-by: David Geier <geidav.pg@gmail.com>
Tested-by: David Geier <geidav.pg@gmail.com>
Discussion: https://postgr.es/m/20200929061142.GA29096%40paquier.xyz
M src/backend/executor/nodeHash.c
M src/backend/executor/nodeHashjoin.c
M src/include/executor/hashjoin.h
Doc: fix documentation example for bytea hex output format.
commit : d28f441d3232ee5b5c3d0c8505618c8696f5db72
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 Mar 2023 16:11:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 Mar 2023 16:11:22 -0400
Per report from rsindlin
Discussion: https://postgr.es/m/167907221210.1803488.5939223864945604536@wrigleys.postgresql.org
M doc/src/sgml/datatype.sgml
Fix pg_dump for hash partitioning on enum columns.
commit : 7e7c5b683985c85fb990c4d49ab960cbc83434b4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Mar 2023 13:31:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Mar 2023 13:31:40 -0400
Hash partitioning on an enum is problematic because the hash codes are
derived from the OIDs assigned to the enum values, which will almost
certainly be different after a dump-and-reload than they were before.
This means that some rows probably end up in different partitions than
before, causing restore to fail because of partition constraint
violations. (pg_upgrade dodges this problem by using hacks to force
the enum values to keep the same OIDs, but that's not possible nor
desirable for pg_dump.)
Users can work around that by specifying --load-via-partition-root,
but since that's a dump-time not restore-time decision, one might
find out the need for it far too late. Instead, teach pg_dump to
apply that option automatically when dealing with a partitioned
table that has hash-on-enum partitioning.
Also deal with a pre-existing issue for --load-via-partition-root
mode: in a parallel restore, we try to TRUNCATE target tables just
before loading them, in order to enable some backend optimizations.
This is bad when using --load-via-partition-root because (a) we're
likely to suffer deadlocks from restore jobs trying to restore rows
into other partitions than they came from, and (b) if we miss getting
a deadlock we might still lose data due to a TRUNCATE removing rows
from some already-completed restore job.
The fix for this is conceptually simple: just don't TRUNCATE if we're
dealing with a --load-via-partition-root case. The tricky bit is for
pg_restore to identify those cases. In dumps using COPY commands we
can inspect each COPY command to see if it targets the nominal target
table or some ancestor. However, in dumps using INSERT commands it's
pretty impractical to examine the INSERTs in advance. To provide a
solution for that going forward, modify pg_dump to mark TABLE DATA
items that are using --load-via-partition-root with a comment.
(This change also responds to a complaint from Robert Haas that
the dump output for --load-via-partition-root is pretty confusing.)
pg_restore checks for the special comment as well as checking the
COPY command if present. This will fail to identify the combination
of --load-via-partition-root and --inserts in pre-existing dump files,
but that should be a pretty rare case in the field. If it does
happen you will probably get a deadlock failure that you can work
around by not using parallel restore, which is the same as before
this bug fix.
Having done this, there seems no remaining reason for the alarmism
in the pg_dump man page about combining --load-via-partition-root
with parallel restore, so remove that warning.
Patch by me; thanks to Julien Rouhaud for review. Back-patch to
v11 where hash partitioning was introduced.
Discussion: https://postgr.es/m/1376149.1675268279@sss.pgh.pa.us
M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_dumpall.sgml
M src/bin/pg_dump/common.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
A src/bin/pg_dump/t/004_pg_dump_parallel.pl
tests: Prevent syslog activity by slapd, take 2
commit : ee880034aac4d315a5aa398c8803715da3d2af97
author : Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 23:03:31 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 23:03:31 -0700
Unfortunately it turns out that the logfile-only option added in b9f8d1cbad7
is only available in openldap starting in 2.6.
Luckily the option to control the log level (loglevel/-s) have been around for
much longer. As it turns out loglevel/-s only control what goes into syslog,
not what ends up in the file specified with 'logfile' and stderr.
While we currently are specifying 'logfile', nothing ends up in it, as the
option only controls debug messages, and we didn't set a debug level. The
debug level can only be configured on the commandline and also prevents
forking. That'd require larger changes, so this commit doesn't tackle that
issue.
Specify the syslog level when starting slapd using -s, as that allows to
prevent all syslog messages if one uses '0' instead of 'none', while loglevel
doesn't prevent the first message.
Discussion: https://postgr.es/m/20230311233708.3yjdbjkly2q4gq2j@awork3.anarazel.de
Backpatch: 11-
M src/test/ldap/t/001_auth.pl
tests: Minimize syslog activity by slapd
commit : f6f5acc6bc1e162d67b3944f18750f0ae13d2e8e
author : Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 17:48:47 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 17:48:47 -0700
Until now the tests using slapd spammed syslog for every connection /
query. Use logfile-only to prevent syslog activity. Unfortunately that only
takes effect after logging the first message, but that's still much better
than the prior situation.
Discussion: https://postgr.es/m/20230311233708.3yjdbjkly2q4gq2j@awork3.anarazel.de
Backpatch: 11-
M src/test/ldap/t/001_auth.pl
Small tidyup for commit d41a178b, part II.
commit : 77a8133c959b9b1facee5fb86755444fe84cd9ce
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 17 Mar 2023 14:44:12 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 17 Mar 2023 14:44:12 +1300
Further to commit 6a9229da, checking for NULL is now redundant. An "out
of memory" error would have been thrown already by palloc() and treated
as FATAL, so we can delete a few more lines.
Back-patch to all releases, like those other commits.
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/4040668.1679013388%40sss.pgh.pa.us
M src/backend/postmaster/postmaster.c
Work around spurious compiler warning in inet operators
commit : 51cb789aa42055ced51d6ba3312ec621133cdc86
author : Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 14:08:44 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 14:08:44 -0700
gcc 12+ has complaints like the following:
../../../../../pgsql/src/backend/utils/adt/network.c: In function 'inetnot':
../../../../../pgsql/src/backend/utils/adt/network.c:1893:34: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
1893 | pdst[nb] = ~pip[nb];
| ~~~~~~~~~^~~~~~~~~~
../../../../../pgsql/src/include/utils/inet.h:27:23: note: at offset -1 into destination object 'ipaddr' of size 16
27 | unsigned char ipaddr[16]; /* up to 128 bits of address */
| ^~~~~~
../../../../../pgsql/src/include/utils/inet.h:27:23: note: at offset -1 into destination object 'ipaddr' of size 16
This is due to a compiler bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
It has been a year since the bug has been reported without getting fixed. As
the warnings are verbose and use of gcc 12 is becoming more common, it seems
worth working around the bug. Particularly because a simple reformulation of
the loop condition fixes the issue and isn't any less readable.
Author: Tom Lane <tgl@sss.pgh.pa.us>
Author: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/144536.1648326206@sss.pgh.pa.us
Backpatch: 11-
M src/backend/utils/adt/network.c
Small tidyup for commit d41a178b.
commit : 798dae9f65e379c0f4f22d7a6096287ea50ffb41
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 17 Mar 2023 09:44:42 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 17 Mar 2023 09:44:42 +1300
A comment was left behind claiming that we needed to use malloc() rather
than palloc() because the corresponding free would run in another
thread, but that's not true anymore. Remove that comment. And, with
the reason being gone, we might as well actually use palloc().
Back-patch to supported releases, like d41a178b.
Discussion: https://postgr.es/m/CA%2BhUKG%2BpdM9v3Jv4tc2BFx2jh_daY3uzUyAGBhtDkotEQDNPYw%40mail.gmail.com
M src/backend/postmaster/postmaster.c
Fix waitpid() emulation on Windows.
commit : 9f1c64018549e28a6f6aa5ad0d5917085520efdd
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 15 Mar 2023 13:17:18 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 15 Mar 2023 13:17:18 +1300
Our waitpid() emulation didn't prevent a PID from being recycled by the
OS before the call to waitpid(). The postmaster could finish up
tracking more than one child process with the same PID, and confuse
them.
Fix, by moving the guts of pgwin32_deadchild_callback() into waitpid(),
so that resources are released synchronously. The process and PID
continue to exist until we close the process handle, which only happens
once we're ready to adjust our book-keeping of running children.
This seems to explain a couple of failures on CI. It had never been
reported before, despite the code being as old as the Windows port.
Perhaps Windows started recycling PIDs more rapidly, or perhaps timing
changes due to commit 7389aad6 made it more likely to break.
Thanks to Alexander Lakhin for analysis and Andres Freund for tracking
down the root cause.
Back-patch to all supported branches.
Reported-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20230208012852.bvkn2am4h4iqjogq%40awork3.anarazel.de
M src/backend/postmaster/postmaster.c
Fix corner case bug in numeric to_char() some more.
commit : 386a26023afb624726fb756ffdbef5b5832caa96
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Mar 2023 19:17:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Mar 2023 19:17:31 -0400
The band-aid applied in commit f0bedf3e4 turns out to still need
some work: it made sure we didn't set Np->last_relevant too small
(to the left of the decimal point), but it didn't prevent setting
it too large (off the end of the partially-converted string).
This could result in fetching data beyond the end of the allocated
space, which with very bad luck could cause a SIGSEGV, though
I don't see any hazard of interesting memory disclosure.
Per bug #17839 from Thiago Nunes. The bug's pretty ancient,
so back-patch to all supported versions.
Discussion: https://postgr.es/m/17839-aada50db24d7b0da@postgresql.org
M src/backend/utils/adt/formatting.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
Fix JSON error reporting for many cases of erroneous string values.
commit : 52e9a781656edefb10e8371d46a1a6d62c1bbb11
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Mar 2023 15:19:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Mar 2023 15:19:00 -0400
The majority of error exit cases in json_lex_string() failed to
set lex->token_terminator, causing problems for the error context
reporting code: it would see token_terminator less than token_start
and do something more or less nuts. In v14 and up the end result
could be as bad as a crash in report_json_context(). Older
versions accidentally avoided that fate; but all versions produce
error context lines that are far less useful than intended,
because they'd stop at the end of the prior token instead of
continuing to where the actually-bad input is.
To fix, invent some macros that make it less notationally painful
to do the right thing. Also add documentation about what the
function is actually required to do; and in >= v14, add an assertion
in report_json_context about token_terminator being sufficiently
far advanced.
Per report from Nikolay Shaplov. Back-patch to all supported
versions.
Discussion: https://postgr.es/m/7332649.x5DLKWyVIX@thinkpad-pgpro
M src/common/jsonapi.c
M src/test/regress/expected/json_encoding.out
M src/test/regress/expected/json_encoding_1.out
Fix failure to detect some cases of improperly-nested aggregates.
commit : bc0bcce2e74bf777b458e3fd815bb125dbda2ce6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Mar 2023 12:40:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Mar 2023 12:40:28 -0400
check_agg_arguments_walker() supposed that it needn't descend into
the arguments of a lower-level aggregate function, but this is
just wrong in the presence of multiple levels of sub-select. The
oversight would lead to executor failures on queries that should
be rejected. (Prior to v11, they actually were rejected, thanks
to a "redundant" execution-time check.)
Per bug #17835 from Anban Company. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/17835-4f29f3098b2d0ba4@postgresql.org
M src/backend/parser/parse_agg.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Fix inconsistent error handling for GSS encryption in PQconnectPoll()
commit : 96bef4374e450b2bd387cbfaad9371db3ac0669a
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 13 Mar 2023 16:36:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 13 Mar 2023 16:36:33 +0900
The error cases for TLS and GSS encryption were inconsistent. After TLS
fails, the connection is marked as dead and follow-up calls of
PQconnectPoll() would return immediately, but GSS encryption was not
doing that, so the connection would still have been allowed to enter the
GSS handling code. This was handled incorrectly when gssencmode was set
to "require". "prefer" was working correctly, and this could not happen
under "disable" as GSS encryption would not be attempted.
This commit makes the error handling of GSS encryption on par with TLS
portion, fixing the case of gssencmode=require.
Reported-by: Jacob Champion
Author: Michael Paquier
Reviewed-by: Jacob Champion, Stephen Frost
Discussion: https://postgr.es/m/23787477-5fe1-a161-6d2a-e459f74c4713@timescale.com
Backpatch-through: 12
M src/interfaces/libpq/fe-connect.c
Mark unsafe_tests module as not runnable with installcheck
commit : baf7f450dbecaf5333e372502a6d7d20c9482af1
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 12 Mar 2023 09:00:32 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 12 Mar 2023 09:00:32 -0400
This was an omission in the original creation of the module.
Also slightly adjust some wording to avoid a double "is".
Backpatch the non-meson piece of this to release 12, where the module
was introduced.
Discussion: https://postgr.es/m/be869e1c-8e3f-4cde-8609-212c899cccf9@dunslane.net
M src/test/modules/unsafe_tests/Makefile
M src/test/modules/unsafe_tests/README
Fix misbehavior in contrib/pg_trgm with an unsatisfiable regex.
commit : bc436e4a917a7185847e05797249ea889214bffe
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 Mar 2023 12:15:41 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 Mar 2023 12:15:41 -0500
If the regex compiler can see that a regex is unsatisfiable
(for example, '$foo') then it may emit an NFA having no arcs.
pg_trgm's packGraph function did the wrong thing in this case;
it would access off the end of a work array, and with bad luck
could produce a corrupted output data structure causing more
problems later. This could end with wrong answers or crashes
in queries using a pg_trgm GIN or GiST index with such a regex.
Fix by not trying to de-duplicate if there aren't at least 2 arcs.
Per bug #17830 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/17830-57ff5f89bdb02b09@postgresql.org
M contrib/pg_trgm/expected/pg_word_trgm.out
M contrib/pg_trgm/sql/pg_word_trgm.sql
M contrib/pg_trgm/trgm_regexp.c
Ensure COPY TO on an RLS-enabled table copies no more than it should.
commit : 866fd004d9f94b87d453642c0c854d38884d3d3d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Mar 2023 13:52:28 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Mar 2023 13:52:28 -0500
The COPY documentation is quite clear that "COPY relation TO" copies
rows from only the named table, not any inheritance children it may
have. However, if you enabled row-level security on the table then
this stopped being true, because the code forgot to apply the ONLY
modifier in the "SELECT ... FROM relation" query that it constructs
in order to allow RLS predicates to be attached. Fix that.
Report and patch by Antonin Houska (comment adjustments and test case
by me). Back-patch to all supported branches.
Discussion: https://postgr.es/m/3472.1675251957@antos
M src/backend/commands/copy.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Fix race in SERIALIZABLE READ ONLY.
commit : ae632f7a31470ca2298bfef79a957dd19678726a
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 9 Mar 2023 16:33:24 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 9 Mar 2023 16:33:24 +1300
Commit bdaabb9b started skipping doomed transactions when building the
list of possible conflicts for SERIALIZABLE READ ONLY. That makes
sense, because doomed transactions won't commit, but a couple of subtle
things broke:
1. If all uncommitted r/w transactions are doomed, a READ ONLY
transaction would arbitrarily not benefit from the safe snapshot
optimization. It would not be taken immediately, and yet no other
transaction would set SXACT_FLAG_RO_SAFE later.
2. In the same circumstances but with DEFERRABLE, GetSafeSnapshot()
would correctly exit its wait loop without sleeping and then take the
optimization in non-assert builds, but assert builds would fail a sanity
check that SXACT_FLAG_RO_SAFE had been set by another transaction.
This is similar to the case for PredXact->WritableSxactCount == 0. We
should opt out immediately if our possibleUnsafeConflicts list is empty
after filtering.
The code to maintain the serializable global xmin is moved down below
the new opt out site, because otherwise we'd have to reverse its effects
before returning.
Back-patch to all supported releases. Bug #17368.
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/17116-d6ca217acc180e30%40postgresql.org
Discussion: https://postgr.es/m/20110707212159.GF76634%40csail.mit.edu
M src/backend/storage/lmgr/predicate.c
Fix corruption due to vacuum_defer_cleanup_age underflowing 64bit xids
commit : e6d77f22c7a8bed88ceef3a3267931f4ce988664
author : Andres Freund <andres@anarazel.de>
date : Tue, 7 Mar 2023 21:36:51 -0800
committer: Andres Freund <andres@anarazel.de>
date : Tue, 7 Mar 2023 21:36:51 -0800
When vacuum_defer_cleanup_age is bigger than the current xid, including the
epoch, the subtraction of vacuum_defer_cleanup_age would lead to a wrapped
around xid. While that normally is not a problem, the subsequent conversion to
a 64bit xid results in a 64bit-xid very far into the future. As that xid is
used as a horizon to detect whether rows versions are old enough to be
removed, that allows removal of rows that are still visible (i.e. corruption).
If vacuum_defer_cleanup_age was never changed from the default, there is no
chance of this bug occurring.
This bug was introduced in dc7420c2c92. A lesser version of it exists in
12-13, introduced by fb5344c969a, affecting only GiST.
The 12-13 version of the issue can, in rare cases, lead to pages in a gist
index getting recycled too early, potentially causing index entries to be
found multiple times.
The fix is fairly simple - don't allow vacuum_defer_cleanup_age to retreat
further than FirstNormalTransactionId.
Patches to make similar bugs easier to find, by adding asserts to the 64bit
xid infrastructure, have been proposed, but are not suitable for backpatching.
Currently there are no tests for vacuum_defer_cleanup_age. A patch introducing
infrastructure to make writing a test easier has been posted to the list.
Reported-by: Michail Nikolaev <michail.nikolaev@gmail.com>
Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com>
Author: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de
Backpatch: 12-, but impact/fix is smaller for 12-13
M src/backend/utils/time/snapmgr.c
Fix more bugs caused by adding columns to the end of a view.
commit : 695b34ab359d84cf8ea94f15852f12bbf04bb038
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Mar 2023 18:21:37 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Mar 2023 18:21:37 -0500
If a view is defined atop another view, and then CREATE OR REPLACE
VIEW is used to add columns to the lower view, then when the upper
view's referencing RTE is expanded by ApplyRetrieveRule we will have
a subquery RTE with fewer eref->colnames than output columns. This
confuses various code that assumes those lists are always in sync,
as they are in plain parser output.
We have seen such problems before (cf commit d5b760ecb), and now
I think the time has come to do what was speculated about in that
commit: let's make ApplyRetrieveRule synthesize some column names to
preserve the invariant that holds in parser output. Otherwise we'll
be chasing this class of bugs indefinitely. Moreover, it appears from
testing that this actually gives us better results in the test case
d5b760ecb added, and likely in other corner cases that we lack
coverage for.
In HEAD, I replaced d5b760ecb's hack to make expandRTE exit early with
an elog(ERROR) call, since the case is now presumably unreachable.
But it seems like changing that in back branches would bring more risk
than benefit, so there I just updated the comment.
Per bug #17811 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/17811-d31686b78f0dffc9@postgresql.org
M src/backend/parser/parse_relation.c
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix some more cases of missed GENERATED-column updates.
commit : 4a94cbd02b2cc637c4a7636a1e7fefee43bff8f6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Mar 2023 18:31:16 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Mar 2023 18:31:16 -0500
If UPDATE is forced to retry after an EvalPlanQual check, it neglected
to repeat GENERATED-column computations, even though those might well
have changed since we're dealing with a different tuple than before.
Fixing this is mostly a matter of looping back a bit further when
we retry. In v15 and HEAD that's most easily done by altering the API
of ExecUpdateAct so that it includes computing GENERATED expressions.
Also, if an UPDATE in a partitioned table turns into a cross-partition
INSERT operation, we failed to recompute GENERATED columns. That's a
bug since 8bf6ec3ba allowed partitions to have different generation
expressions; although it seems to have no ill effects before that.
Fixing this is messier because we can now have situations where the same
query needs both the UPDATE-aligned set of GENERATED columns and the
INSERT-aligned set, and it's unclear which set will be generated first
(else we could hack things by forcing the INSERT-aligned set to be
generated, which is indeed how fe9e658f4 made it work for MERGE).
The best fix seems to be to build and store separate sets of expressions
for the INSERT and UPDATE cases. That would create ABI issues in the
back branches, but so far it seems we can leave this alone in the back
branches.
Per bug #17823 from Hisahiro Kauchi. The first part of this affects all
branches back to v12 where GENERATED columns were added.
Discussion: https://postgr.es/m/17823-b64909cf7d63de84@postgresql.org
M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql
Fix assert failures in parallel SERIALIZABLE READ ONLY.
commit : a0f55fc86ab7adde027351f5c9596a3814ddea83
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 6 Mar 2023 15:07:15 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 6 Mar 2023 15:07:15 +1300
1. Make sure that we don't decrement SxactGlobalXminCount twice when
the SXACT_FLAG_RO_SAFE optimization is reached in a parallel query.
This could trigger a sanity check failure in assert builds. Non-assert
builds recompute the count in SetNewSxactGlobalXmin(), so the problem
was hidden, explaining the lack of field reports. Add a new isolation
test to exercise that case.
2. Remove an assertion that the DOOMED flag can't be set on a partially
released SERIALIZABLEXACT. Instead, ignore the flag (our transaction
was already determined to be read-only safe, and DOOMED is in fact set
during partial release, and there was already an assertion that it
wasn't set sooner). Improve an existing isolation test so that it
reaches that case (previously it wasn't quite testing what it was
supposed to be testing; see discussion).
Back-patch to 12. Bug #17116. Defects in commit 47a338cf.
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/17116-d6ca217acc180e30%40postgresql.org
M src/backend/storage/lmgr/predicate.c
M src/test/isolation/expected/serializable-parallel-2.out
A src/test/isolation/expected/serializable-parallel-3.out
M src/test/isolation/isolation_schedule
M src/test/isolation/specs/serializable-parallel-2.spec
A src/test/isolation/specs/serializable-parallel-3.spec
Avoid fetching one past the end of translate()'s "to" parameter.
commit : 3b37e844220d4e7cedbb8def7fbcd2b36703d65d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Mar 2023 11:30:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Mar 2023 11:30:17 -0500
This is usually harmless, but if you were very unlucky it could
provoke a segfault due to the "to" string being right up against
the end of memory. Found via valgrind testing (so we might've
found it earlier, except that our regression tests lacked any
exercise of translate()'s deletion feature).
Fix by switching the order of the test-for-end-of-string and
advance-pointer steps. While here, compute "to_ptr + tolen"
just once. (Smarter compilers might figure that out for
themselves, but let's just make sure.)
Report and fix by Daniil Anisimov, in bug #17816.
Discussion: https://postgr.es/m/17816-70f3d2764e88a108@postgresql.org
M src/backend/utils/adt/oracle_compat.c
M src/test/regress/expected/strings.out
M src/test/regress/sql/strings.sql
Don't force SQL_ASCII/no-locale for installcheck in vcregress.pl
commit : ab5b76c07a0e920f106228a5e54043cb5cd298b7
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 26 Feb 2023 06:48:41 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 26 Feb 2023 06:48:41 -0500
It's been this way for a very long time, but it appears to have been
masking an issue that only manifests with different settings. Therefore,
run the tests in the installation's default encoding/locale.
Backpatch to all live branches.
M src/tools/msvc/vcregress.pl
Fix MULTIEXPR_SUBLINK with partitioned target tables, yet again.
commit : 1e199c25994791842fe2f80c0809c2e69a3a7d2e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Feb 2023 14:44:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Feb 2023 14:44:14 -0500
We already tried to fix this in commits 3f7323cbb et al (and follow-on
fixes), but now it emerges that there are still unfixed cases;
moreover, these cases affect all branches not only pre-v14. I thought
we had eliminated all cases of making multiple clones of an UPDATE's
target list when we nuked inheritance_planner. But it turns out we
still do that in some partitioned-UPDATE cases, notably including
INSERT ... ON CONFLICT UPDATE, because ExecInitPartitionInfo thinks
it's okay to clone and modify the parent's targetlist.
This fix is based on a suggestion from Andres Freund: let's stop
abusing the ParamExecData.execPlan mechanism, which was only ever
meant to handle initplans, and instead solve the execution timing
problem by having the expression compiler move MULTIEXPR_SUBLINK steps
to the front of their expression step lists. This is feasible because
(a) all branches still in support compile the entire targetlist of
an UPDATE into a single ExprState, and (b) we know that all
MULTIEXPR_SUBLINKs do need to be evaluated --- none could be buried
inside a CASE, for example. There is a minor semantics change
concerning the order of execution of the MULTIEXPR's subquery versus
other parts of the parent targetlist, but that seems like something
we can get away with. By doing that, we no longer need to worry
about whether different clones of a MULTIEXPR_SUBLINK share output
Params; their usage of that data structure won't overlap.
Per bug #17800 from Alexander Lakhin. Back-patch to all supported
branches. In v13 and earlier, we can revert 3f7323cbb and follow-on
fixes; however, I chose to keep the SubPlan.subLinkId field added
in ccbb54c72. We don't need that anymore in the core code, but it's
cheap enough to fill, and removing a plan node field in a minor
release seems like it'd be asking for trouble.
Andres Freund and Tom Lane
Discussion: https://postgr.es/m/17800-ff90866b3906c964@postgresql.org
M src/backend/executor/execExpr.c
M src/backend/executor/nodeSubplan.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/subselect.c
M src/include/nodes/primnodes.h
M src/include/optimizer/subselect.h
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Fix mishandling of OLD/NEW references in subqueries in rule actions.
commit : 39ad791e851022bc88feca4637118e7b589f5f3a
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 25 Feb 2023 14:45:44 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 25 Feb 2023 14:45:44 +0000
If a rule action contains a subquery that refers to columns from OLD
or NEW, then those are really lateral references, and the planner will
complain if it sees such things in a subquery that isn't marked as
lateral. However, at rule-definition time, the user isn't required to
mark the subquery with LATERAL, and so it can fail when the rule is
used.
Fix this by marking such subqueries as lateral in the rewriter, at the
point where they're used.
Dean Rasheed and Tom Lane, per report from Alexander Lakhin.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/5e09da43-aaba-7ea7-0a51-a2eb981b058b%40gmail.com
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql
Don't repeatedly register cache callbacks in pgoutput plugin.
commit : 861e9e48601b41ab3827ba5d22990c17ed6dcf8c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 23 Feb 2023 15:40:28 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 23 Feb 2023 15:40:28 -0500
Multiple cycles of starting up and shutting down the plugin within a
single session would eventually lead to "out of relcache_callback_list
slots", because pgoutput_startup blindly re-registered its cache
callbacks each time. Fix it to register them only once, as all other
users of cache callbacks already take care to do.
This has been broken all along, so back-patch to all supported branches.
Shi Yu
Discussion: https://postgr.es/m/OSZPR01MB631004A78D743D68921FFAD3FDA79@OSZPR01MB6310.jpnprd01.prod.outlook.com
M src/backend/replication/pgoutput/pgoutput.c
Fix multi-row DEFAULT handling for INSERT ... SELECT rules.
commit : 226da3d4767083b58b9d1acf67b1402865d359bf
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 23 Feb 2023 10:56:41 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 23 Feb 2023 10:56:41 +0000
Given an updatable view with a DO ALSO INSERT ... SELECT rule, a
multi-row INSERT ... VALUES query on the view fails if the VALUES list
contains any DEFAULTs that are not replaced by view defaults. This
manifests as an "unrecognized node type" error, or an Assert failure,
in an assert-enabled build.
The reason is that when RewriteQuery() attempts to replace the
remaining DEFAULT items with NULLs in any product queries, using
rewriteValuesRTEToNulls(), it assumes that the VALUES RTE is located
at the same rangetable index in each product query. However, if the
product query is an INSERT ... SELECT, then the VALUES RTE is actually
in the SELECT part of that query (at the same index), rather than the
top-level product query itself.
Fix, by descending to the SELECT in such cases. Note that we can't
simply use getInsertSelectQuery() for this, since that expects to be
given a raw rule action with OLD and NEW placeholder entries, so we
duplicate its logic instead.
While at it, beef up the checks in getInsertSelectQuery() by checking
that the jointree->fromlist node is indeed a RangeTblRef, and that the
RTE it points to has rtekind == RTE_SUBQUERY.
Per bug #17803, from Alexander Lakhin. Back-patch to all supported
branches.
Dean Rasheed, reviewed by Tom Lane.
Discussion: https://postgr.es/m/17803-53c63ed4ecb4eac6%40postgresql.org
M src/backend/rewrite/rewriteHandler.c
M src/backend/rewrite/rewriteManip.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Fix snapshot handling in logicalmsg_decode
commit : 4df581fa0f4b663141901d87817f77ec695c6d22
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 22 Feb 2023 15:24:09 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 22 Feb 2023 15:24:09 +0100
Whe decoding a transactional logical message, logicalmsg_decode called
SnapBuildGetOrBuildSnapshot. But we may not have a consistent snapshot
yet at that point. We don't actually need the snapshot in this case
(during replay we'll have the snapshot from the transaction), so in
practice this is harmless. But in assert-enabled build this crashes.
Fixed by requesting the snapshot only in non-transactional case, where
we are guaranteed to have SNAPBUILD_CONSISTENT.
Backpatch to 11. The issue exists since 9.6.
Backpatch-through: 11
Reviewed-by: Andres Freund
Discussion: https://postgr.es/m/84d60912-6eab-9b84-5de3-41765a5449e8@enterprisedb.com
M src/backend/replication/logical/decode.c
M src/backend/replication/logical/reorderbuffer.c
Add missing support for the latest SPI status codes.
commit : 906356cf6128ac6e35bcb07f7fd5361eb76c4999
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 22 Feb 2023 13:27:29 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 22 Feb 2023 13:27:29 +0000
SPI_result_code_string() was missing support for SPI_OK_TD_REGISTER,
and in v15 and later, it was missing support for SPI_OK_MERGE, as was
pltcl_process_SPI_result().
The last of those would trigger an error if a MERGE was executed from
PL/Tcl. The others seem fairly innocuous, but worth fixing.
Back-patch to all supported branches. Before v15, this is just adding
SPI_OK_TD_REGISTER to SPI_result_code_string(), which is unlikely to
be seen by anyone, but seems worth doing for completeness.
Reviewed by Tom Lane.
Discussion:
https://postgr.es/m/CAEZATCUg8V%2BK%2BGcafOPqymxk84Y_prXgfe64PDoopjLFH6Z0Aw%40mail.gmail.com
https://postgr.es/m/CAEZATCUMe%2B_KedPMM9AxKqm%3DSZogSxjUcrMe%2BsakusZh3BFcQw%40mail.gmail.com
M src/backend/executor/spi.c
Fix erroneous Valgrind markings in AllocSetRealloc.
commit : 99e74cd235a5cb7d58eadfc627e4e1b1ebac1231
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Feb 2023 18:47:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Feb 2023 18:47:47 -0500
If asked to decrease the size of a large (>8K) palloc chunk,
AllocSetRealloc could improperly change the Valgrind state of memory
beyond the new end of the chunk: it would mark data UNDEFINED as far
as the old end of the chunk after having done the realloc(3) call,
thus tromping on the state of memory that no longer belongs to it.
One would normally expect that memory to now be marked NOACCESS,
so that this mislabeling might prevent detection of later errors.
If realloc() had chosen to move the chunk someplace else (unlikely,
but well within its rights) we could also mismark perfectly-valid
DEFINED data as UNDEFINED, causing false-positive valgrind reports
later. Also, any malloc bookkeeping data placed within this area
might now be wrongly marked, causing additional problems.
Fix by replacing relevant uses of "oldsize" with "Min(size, oldsize)".
It's sufficient to mark as far as "size" when that's smaller, because
whatever remains in the new chunk size will be marked NOACCESS below,
and we expect realloc() to have taken care of marking the memory
beyond the new official end of the chunk.
While we're here, also rename the function's "oldsize" variable
to "oldchksize" to more clearly explain what it actually holds,
namely the distance to the end of the chunk (that is, requested size
plus trailing padding). This is more consistent with the use of
"size" and "chksize" to hold the new requested size and chunk size.
Add a new variable "oldsize" in the one stanza where we're actually
talking about the old requested size.
Oversight in commit c477f3e44. Back-patch to all supported branches,
as that was, just in case anybody wants to do valgrind testing on back
branches.
Karina Litskevich
Discussion: https://postgr.es/m/CACiT8iaAET-fmzjjZLjaJC4zwSJmrFyL7LAdHwaYyjjQOQ4hcg@mail.gmail.com
M src/backend/utils/mmgr/aset.c
Print the correct aliases for DML target tables in ruleutils.
commit : 4efb4f0d48787fbdf42c0b760f19c997664f0d56
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Feb 2023 16:40:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Feb 2023 16:40:34 -0500
ruleutils.c blindly printed the user-given alias (or nothing if there
hadn't been one) for the target table of INSERT/UPDATE/DELETE queries.
That works a large percentage of the time, but not always: for queries
appearing in WITH, it's possible that we chose a different alias to
avoid conflict with outer-scope names. Since the chosen alias would
be used in any Var references to the target table, this'd lead to an
inconsistent printout with consequences such as dump/restore failures.
The correct logic for printing (or not) a relation alias was embedded
in get_from_clause_item. Factor it out to a separate function so that
we don't need a jointree node to use it. (Only a limited part of that
function can be reached from these new call sites, but this seems like
the cleanest non-duplicative factorization.)
In passing, I got rid of a redundant "\d+ rules_src" step in rules.sql.
Initial report from Jonathan Katz; thanks to Vignesh C for analysis.
This has been broken for a long time, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/e947fa21-24b2-f922-375a-d4f763ef3e4b@postgresql.org
Discussion: https://postgr.es/m/CALDaNm1MMntjmT_NJGp-Z=xbF02qHGAyuSHfYHias3TqQbPF2w@mail.gmail.com
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
commit : 2eb8e54cc373e4e4f9ecf7360563912f9c40ad76
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 15 Feb 2023 10:12:36 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 15 Feb 2023 10:12:36 +0900
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
M configure
M configure.in
M src/backend/libpq/be-secure-openssl.c
M src/include/libpq/libpq-be.h
M src/include/pg_config.h.in
M src/interfaces/libpq/fe-secure-openssl.c
M src/interfaces/libpq/libpq-int.h
M src/tools/msvc/Solution.pm
Disable WindowAgg inverse transitions when subplans are present
commit : 301eb3ee4ecd366c92bc8ecda9c42c3760e018c1
author : David Rowley <drowley@postgresql.org>
date : Mon, 13 Feb 2023 17:09:26 +1300
committer: David Rowley <drowley@postgresql.org>
date : Mon, 13 Feb 2023 17:09:26 +1300
When an aggregate function is used as a WindowFunc and a tuple transitions
out of the window frame, we ordinarily try to make use of the aggregate
function's inverse transition function to "unaggregate" the exiting tuple.
This optimization is disabled for various cases, including when the
aggregate contains a volatile function. In such a case we'd be unable to
ensure that the transition value was calculated to the same value during
transitions and inverse transitions. Unfortunately, we did this check by
calling contain_volatile_functions() which does not recursively search
SubPlans for volatile functions. If the aggregate function's arguments or
its FILTER clause contained a subplan with volatile functions then we'd
fail to notice this.
Here we fix this by just disabling the optimization when the WindowFunc
contains any subplans. Volatile functions are not the only reason that a
subplan may have nonrepeatable results.
Bug: #17777
Reported-by: Anban Company
Discussion: https://postgr.es/m/17777-860b739b6efde977%40postgresql.org
Reviewed-by: Tom Lane
Backpatch-through: 11
M src/backend/executor/nodeWindowAgg.c
Stop recommending auto-download of DTD files, and indeed disable it.
commit : c7b608600547426b1a3181f9b6d4d2e117624e1e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Feb 2023 17:15:23 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Feb 2023 17:15:23 -0500
It appears no longer possible to build the SGML docs without a local
installation of the DocBook DTD, because sourceforge.net now only
permits HTTPS access, and no common version of xsltproc supports that.
Hence, remove the bits of our documentation suggesting that that's
possible or useful.
In fact, we might as well add the --nonet option to the build recipes
automatically, for a bit of extra security.
Also fix our documentation-tool-installation recipes for macOS to
ensure that xmllint and xsltproc are pulled in from MacPorts or
Homebrew. The previous recipes assumed you could use the
Apple-supplied versions of these tools; which still works, except that
you'd need to set an environment variable to ensure that they would
find DTD files provided by those package managers. Simpler and easier
to just recommend pulling in the additional packages.
In HEAD, also document how to build docs using Meson, and adjust
"ninja docs" to just build the HTML docs, for consistency with the
default behavior of doc/src/sgml/Makefile.
In a fit of neatnik-ism, I also made the ordering of the package
lists match the order in which the tools are described at the head
of the appendix.
Aleksander Alekseev, Peter Eisentraut, Tom Lane
Discussion: https://postgr.es/m/CAJ7c6TO8Aro2nxg=EQsVGiSDe-TstP4EsSvDHd7DSRsP40PgGA@mail.gmail.com
M doc/src/sgml/Makefile
M doc/src/sgml/docguide.sgml
M doc/src/sgml/images/Makefile
Make EXEC_BACKEND more convenient on Linux and FreeBSD.
commit : 1e4fda6da918f734dd6dab67b3ddcaba4c2fecb2
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 8 Feb 2023 13:09:49 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 8 Feb 2023 13:09:49 +0900
Try to disable ASLR when building in EXEC_BACKEND mode, to avoid random
memory mapping failures while testing. For developer use only, no
effect on regular builds.
This has been originally applied as of f3e7806 for v15~, but
recently-added buildfarm member gokiburi tests this configuration on
older branches as well, causing it to fail randomly as ASLR would be
enabled.
Suggested-by: Andres Freund <andres@anarazel.de>
Tested-by: Bossart, Nathan <bossartn@amazon.com>
Discussion: https://postgr.es/m/20210806032944.m4tz7j2w47mant26%40alap3.anarazel.de
Backpatch-through: 12
M configure
M configure.in
M src/bin/pg_ctl/pg_ctl.c
M src/common/exec.c
M src/include/pg_config.h.in
M src/include/port.h
M src/test/regress/pg_regress.c
M src/tools/msvc/Solution.pm
Stamp 13.10.
commit : 20aba55fae83cd0b6f7511365d172da8cd7e0135
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2023 16:42:56 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2023 16:42:56 -0500
M configure
M configure.in
Last-minute updates for release notes.
commit : 6926350d6b90181193e776d3313c49226cbca2ea
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2023 11:43:10 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2023 11:43:10 -0500
Security: CVE-2022-41862
M doc/src/sgml/release-13.sgml
Translation updates
commit : 07113f15cd123aa2279cb37e0e848766e050225b
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 6 Feb 2023 12:18:46 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 6 Feb 2023 12:18:46 +0100
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: a7bebd06a02093ea07899fc0804adeb372126620
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/initdb/po/ru.po
M src/bin/pg_archivecleanup/po/ru.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetwal/po/ru.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_test_fsync/po/ru.po
M src/bin/pg_test_timing/po/ru.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_verifybackup/po/ru.po
M src/bin/pg_waldump/po/ru.po
M src/bin/psql/po/de.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/ru.po
Properly NULL-terminate GSS receive buffer on error packet reception
commit : 45a945ee97b8b55a45d2ff5d4f4944b1e2dcacb8
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 6 Feb 2023 11:20:27 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 6 Feb 2023 11:20:27 +0900
pqsecure_open_gss() includes a code path handling error messages with
v2-style protocol messages coming from the server. The client-side
buffer holding the error message does not force a NULL-termination, with
the data of the server getting copied to the errorMessage of the
connection. Hence, it would be possible for a server to send an
unterminated string and copy arbitrary bytes in the buffer receiving the
error message in the client, opening the door to a crash or even data
exposure.
As at this stage of the authentication process the exchange has not been
completed yet, this could be abused by an attacker without Kerberos
credentials. Clients that have a valid kerberos cache are vulnerable as
libpq opportunistically requests for it except if gssencmode is
disabled.
Author: Jacob Champion
Backpatch-through: 12
Security: CVE-2022-41862
M src/interfaces/libpq/fe-secure-gssapi.c
Release notes for 15.2, 14.7, 13.10, 12.14, 11.19.
commit : 70192be7bd9ecc5e1e18989ab7a90ac00ce90e9b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Feb 2023 16:22:32 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Feb 2023 16:22:32 -0500
M doc/src/sgml/release-13.sgml
doc: Fix XML formatting that psql cannot handle
commit : c7b31ecc27f4056a40e17432dc17c1aeffe5d117
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 3 Feb 2023 09:04:35 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 3 Feb 2023 09:04:35 +0100
Breaking <phrase> over two lines is not handled by psql's
create_help.pl. (It creates faulty \help output.)
Undo the formatting change introduced by
9bdad1b5153e5d6b77a8f9c6e32286d6bafcd76d to fix this for now.
M doc/src/sgml/ref/fetch.sgml
M doc/src/sgml/ref/move.sgml
Update time zone data files to tzdata release 2022g.
commit : 20d9da10727d6562ca11e18b1e65cf6174d3902e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Jan 2023 17:36:55 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Jan 2023 17:36:55 -0500
DST law changes in Greenland and Mexico. Notably, a new timezone
America/Ciudad_Juarez has been split off from America/Ojinaga.
Historical corrections for northern Canada, Colombia, and Singapore.
M src/timezone/data/tzdata.zi
Doc: clarify use of NULL to drop comments and security labels.
commit : 5fb1809eb966ec04ce2ec8fa4f0c382092659f03
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Jan 2023 14:32:24 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Jan 2023 14:32:24 -0500
This was only mentioned in the description of the text/label, which
are marked as being in quotes in the synopsis, which can cause
confusion (as witnessed on IRC).
Also separate the literal and NULL cases in the parameter list, per
suggestion from Tom Lane.
Also add an example of dropping a security label.
Dagfinn Ilmari Mannsåker, with some tweaks by me
Discussion: https://postgr.es/m/87sffqk4zp.fsf@wibble.ilmari.org
M doc/src/sgml/ref/comment.sgml
M doc/src/sgml/ref/security_label.sgml
Remove recovery test 011_crash_recovery.pl
commit : ee11824ac4c228b354c71991d7ef14c4496bcfe5
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 31 Jan 2023 12:47:15 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 31 Jan 2023 12:47:15 +0900
This test has been added as of 857ee8e that has introduced the SQL
function txid_status(), with the purpose of checking that a transaction
ID still in-progress during a crash is correctly marked as aborted after
recovery finishes.
This test is unstable, and some configuration scenarios may that easier
to reproduce (wal_level=minimal, wal_compression=on) because the WAL
holding the information about the in-progress transaction ID may not
have made it to disk yet, hence a post-crash recovery may cause the same
XID to be reused, triggering a test failure.
We have discussed a few approaches, like making this function force a
WAL flush to make it reliable across crashes, but we don't want to pay a
performance penalty in some scenarios, as well. The test could have
been tweaked to enforce a checkpoint but that actually breaks the
promise of the test to rely on a stable result of txid_status() after
a crash.
This issue has been reported a few times across the past years, with an
original report from Kyotaro Horiguchi. The buildfarm machines tanager,
hachi and gokiburi enable wal_compression, and fail on this test
periodically.
Discussion: https://postgr.es/m/3163112.1674762209@sss.pgh.pa.us
Discussion: https://postgr.es/m/20210305.115011.558061052471425531.horikyota.ntt@gmail.com
Backpatch-through: 11
D src/test/recovery/t/011_crash_recovery.pl
Fix rare sharedtuplestore.c corruption.
commit : 1a5afe007779b677c4f2e411f8d9af23f7a2d085
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 26 Jan 2023 14:50:07 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 26 Jan 2023 14:50:07 +1300
If the final chunk of an oversized tuple being written out to disk was
exactly 32760 bytes, it would be corrupted due to a fencepost bug.
Bug #17619. Back-patch to 11 where the code arrived.
While testing that (see test module in archives), I (tmunro) noticed
that the per-participant page counter was not initialized to zero as it
should have been; that wasn't a live bug when it was written since DSM
memory was originally always zeroed, but since 14
min_dynamic_shared_memory might be configured and it supplies non-zeroed
memory, so that is also fixed here.
Author: Dmitry Astapov <dastapov@gmail.com>
Discussion: https://postgr.es/m/17619-0de62ceda812b8b5%40postgresql.org
M src/backend/utils/sort/sharedtuplestore.c
Fix error handling in libpqrcv_connect()
commit : c5864805ba99f79b49b12dc14499da58b0e15eb8
author : Andres Freund <andres@anarazel.de>
date : Mon, 23 Jan 2023 18:04:02 -0800
committer: Andres Freund <andres@anarazel.de>
date : Mon, 23 Jan 2023 18:04:02 -0800
When libpqrcv_connect (also known as walrcv_connect()) failed, it leaked the
libpq connection. In most paths that's fairly harmless, as the calling process
will exit soon after. But e.g. CREATE SUBSCRIPTION could lead to a somewhat
longer lived leak.
Fix by releasing resources, including the libpq connection, on error.
Add a test exercising the error code path. To make it reliable and safe, the
test tries to connect to port=-1, which happens to fail during connection
establishment, rather than during connection string parsing.
Reviewed-by: Noah Misch <noah@leadboat.com>
Discussion: https://postgr.es/m/20230121011237.q52apbvlarfv6jm6@awork3.anarazel.de
Backpatch: 11-
M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
M src/test/regress/expected/subscription.out
M src/test/regress/sql/subscription.sql
Allow REPLICA IDENTITY to be set on an index that's not (yet) valid.
commit : 72d611109e65e279aa5719aba9831761f6f6c368
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Jan 2023 13:10:29 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Jan 2023 13:10:29 -0500
The motivation for this change is that when pg_dump dumps a
partitioned index that's marked REPLICA IDENTITY, it generates a
command sequence that applies REPLICA IDENTITY before the partitioned
index has been marked valid, causing restore to fail. We could
perhaps change pg_dump to not do it like that, but that would be
difficult and would not fix existing dump files with the problem.
There seems to be very little reason for the backend to disallow
this anyway --- the code ignores indisreplident when the index
isn't valid --- so instead let's fix it by allowing the case.
Commit 9511fb37a previously expressed a concern that allowing
indisreplident to be set on invalid indexes might allow us to
wind up in a situation where a table could have indisreplident
set on multiple indexes. I'm not sure I follow that concern
exactly, but in any case the only way that could happen is because
relation_mark_replica_identity is too trusting about the existing set
of markings being valid. Let's just rip out its early-exit code path
(which sure looks like premature optimization anyway; what are we
doing expending code to make redundant ALTER TABLE ... REPLICA
IDENTITY commands marginally faster and not-redundant ones marginally
slower?) and fix it to positively guarantee that no more than one
index is marked indisreplident.
The pg_dump failure can be demonstrated in all supported branches,
so back-patch all the way. I chose to back-patch 9511fb37a as well,
just to keep indisreplident handling the same in all branches.
Per bug #17756 from Sergey Belyashov.
Discussion: https://postgr.es/m/17756-dd50e8e0c8dd4a40@postgresql.org
M src/backend/catalog/index.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/replica_identity.out
M src/test/regress/sql/replica_identity.sql
Reject CancelRequestPacket having unexpected length.
commit : a9bccffe5a39dab64ca597476563f8d965b46428
author : Noah Misch <noah@leadboat.com>
date : Sat, 21 Jan 2023 06:08:00 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sat, 21 Jan 2023 06:08:00 -0800
When the length was too short, the server read outside the allocation.
That yielded the same log noise as sending the correct length with
(backendPID,cancelAuthCode) matching nothing. Change to a message about
the unexpected length. Given the attacker's lack of control over the
memory layout and the general lack of diversity in memory layouts at the
code in question, we doubt a would-be attacker could cause a segfault.
Hence, while the report arrived via security@postgresql.org, this is not
a vulnerability. Back-patch to v11 (all supported versions).
Andrey Borodin, reviewed by Tom Lane. Reported by Andrey Borodin.
M src/backend/postmaster/postmaster.c
Make our back branches build under -fkeep-inline-functions.
commit : c78f109b87d8a64b0f785bf6fa30d4bd29742638
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Jan 2023 11:58:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Jan 2023 11:58:12 -0500
Add "#ifndef FRONTEND" where necessary to make pg_waldump build
on compilers that don't elide unused static-inline functions.
This back-patches relevant parts of commit 3e9ca5260, fixing build
breakage from dc7420c2c and back-patching of f10f0ae42.
Per recently-resurrected buildfarm member castoroides. We aren't
expecting castoroides to build anything newer than v11, but we
might as well clean up the intermediate branches while at it.
M src/include/utils/rel.h
Log the correct ending timestamp in recovery_target_xid mode.
commit : 1b9a0b96a8701ddcd147836241f89d616772d332
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Jan 2023 12:23:20 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Jan 2023 12:23:20 -0500
When ending recovery based on recovery_target_xid matching with
recovery_target_inclusive = off, we printed an incorrect timestamp
(always 2000-01-01) in the "recovery stopping before ... transaction"
log message. This is a consequence of sloppy refactoring in
c945af80c: the code to fetch recordXtime out of the commit/abort
record used to be executed unconditionally, but it was changed
to get called only in the RECOVERY_TARGET_TIME case. We need only
flip the order of operations to restore the intended behavior.
Per report from Torsten Förtsch. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/CAKkG4_kUevPqbmyOfLajx7opAQk6Cvwkvx0HRcFjSPfRPTXanA@mail.gmail.com
M src/backend/access/transam/xlog.c
Add missing assign hook for GUC checkpoint_completion_target
commit : fed4e92f3bfd4dfbbee472fb4b0b86d9b9100a3c
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 13:13:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 13:13:30 +0900
This is wrong since 88e9823, that has switched the WAL sizing
configuration from checkpoint_segments to min_wal_size and
max_wal_size. This missed the recalculation of the internal value of
the internal "CheckPointSegments", that works as a mapping of the old
GUC checkpoint_segments, on reload, for example, and it controls the
timing of checkpoints depending on the volume of WAL generated.
Most users tend to leave checkpoint_completion_target at 0.9 to smooth
the I/O workload, which is why I guess this has gone unnoticed for so
long, still it can be useful to tweak and reload the value dynamically
in some cases to control the timing of checkpoints.
Author: Bharath Rupireddy
Discussion: https://postgr.es/m/CALj2ACXgPPAm28mruojSBno+F_=9cTOOxHAywu_dfZPeBdybQw@mail.gmail.com
Backpatch-through: 11
M src/backend/utils/misc/guc.c
Fix failure with perlcritic in psql's create_help.pl
commit : dfe96d6130694e43bf078de0c9e39b55bc222b7a
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 10:02:12 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 10:02:12 +0900
No buildfarm members have reported that yet, but a recently-refreshed
Debian host did.
Reviewed-by: Andrew Dunstan
Discussion: https://postgr.es/m/Y8ey5z4Nav62g4/K@paquier.xyz
Backpatch-through: 11
M src/bin/psql/create_help.pl
AdjustUpgrade.pm should zap test_ext_cine, too.
commit : 1136d81bfa7f902a14fd426a97ecd99381d72953
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Jan 2023 16:00:39 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Jan 2023 16:00:39 -0500
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/AdjustUpgrade.pm
Create common infrastructure for cross-version upgrade testing.
commit : 3f0b9df88bb33ec52b0af8b11295d256d2011e29
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 16 Jan 2023 20:35:53 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/891521.1673657296@sss.pgh.pa.us
D src/bin/pg_upgrade/upgrade_adapt.sql
A src/test/perl/PostgreSQL/Test/AdjustUpgrade.pm
A src/test/perl/PostgreSQL/Version.pm
Fix some BufFileRead() error reporting
commit : cf74b6eadb9d8fcfd51a99e9cc6b04d019e36b12
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 16 Jan 2023 09:20:44 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 16 Jan 2023 09:20:44 +0100
Remove "%m" from error messages where errno would be bogus. Add short
read byte counts where appropriate.
This is equivalent to what was done in
7897e3bb902c557412645b82120f4d95f7474906, but some code was apparently
developed concurrently to that and not updated accordingly.
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/f3501945-c591-8cc3-5ef0-b72a2e0eaa9c@enterprisedb.com
M src/backend/replication/backup_manifest.c
Make new GENERATED-expressions code more bulletproof.
commit : 787db4be947c2be419c4e97ba9d611708f2523c5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Jan 2023 14:06:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Jan 2023 14:06:46 -0500
In commit 8bf6ec3ba I assumed that no code path could reach
ExecGetExtraUpdatedCols without having gone through
ExecInitStoredGenerated. That turns out not to be the case in
logical replication: if there's an ON UPDATE trigger on the target
table, trigger.c will call this code before anybody has set up its
generated columns. Having seen that, I don't have a lot of faith in
there not being other such paths. ExecGetExtraUpdatedCols can call
ExecInitStoredGenerated for itself, as long as we are willing to
assume that it is only called in CMD_UPDATE operations, which on
the whole seems like a safer leap of faith.
Per report from Vitaly Davydov.
Discussion: https://postgr.es/m/d259d69652b8c2ff50e14cda3c236c7f@postgrespro.ru
M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/include/executor/nodeModifyTable.h
M src/test/subscription/t/011_generated.pl
Fix WaitEventSetWait() buffer overrun.
commit : c159b0383fa6412686abfb4e6de9face87d2b0cc
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 13 Jan 2023 10:40:52 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 13 Jan 2023 10:40:52 +1300
The WAIT_USE_EPOLL and WAIT_USE_KQUEUE implementations of
WaitEventSetWaitBlock() confused the size of their internal buffer with
the size of the caller's output buffer, and could ask the kernel for too
many events. In fact the set of events retrieved from the kernel needs
to be able to fit in both buffers, so take the smaller of the two.
The WAIT_USE_POLL and WAIT_USE WIN32 implementations didn't have this
confusion.
This probably didn't come up before because we always used the same
number in both places, but commit 7389aad6 calculates a dynamic size at
construction time, while using MAXLISTEN for its output event buffer on
the stack. That seems like a reasonable thing to want to do, so
consider this to be a pre-existing bug worth fixing.
As discovered by valgrind on skink.
Back-patch to all supported releases for epoll, and to release 13 for
the kqueue part, which copied the incorrect epoll code.
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/901504.1673504836%40sss.pgh.pa.us
M src/backend/storage/ipc/latch.c
Fix jsonpath existense checking of missing variables
commit : 2ff3ac3b5f52a54b829cc7275141839581b568de
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 12 Jan 2023 18:16:34 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 12 Jan 2023 18:16:34 +0300
The current jsonpath code assumes that the referenced variable always exists.
It could only throw an error at the value valuation time. At the same time
existence checking assumes variable is present without valuation, and error
suppression doesn't work for missing variables.
This commit makes existense checking trigger an error for missing variables.
This makes the overall behavior consistent.
Backpatch to 12 where jsonpath was introduced.
Reported-by: David G. Johnston
Discussion: https://postgr.es/m/CAKFQuwbeytffJkVnEqDyLZ%3DrQsznoTh1OgDoOF3VmOMkxcTMjA%40mail.gmail.com
Author: Alexander Korotkov, David G. Johnston
Backpatch-through: 12
M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/sql/jsonb_jsonpath.sql
Avoid using tuple from syscache for update of pg_database.datfrozenxid
commit : 72b6098be47e19eff50a052676908e0fde25e7ee
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 11 Jan 2023 09:56:14 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 11 Jan 2023 09:56:14 +0900
pg_database.datfrozenxid gets updated using an in-place update at the
end of vacuum or autovacuum. Since 96cdeae, as pg_database has a toast
relation, it is possible for a pg_database tuple to have toast values
if there is a large set of ACLs in place. In such a case, the in-place
update would fail because of the flattening of the toast values done for
the catcache entry fetched. Instead of using a copy from the catcache,
this changes the logic to fetch the copy of the tuple by directly
scanning pg_database.
Note that before 96cdeae, attempting to insert such a tuple to
pg_database would cause a "row is too big" error, so the end-of-vacuum
problem was not reachable.
This issue has been originally fixed in 947789f on v14~, and there have
been reports about this problem on v12 and v13, causing failures at the
end of VACUUM. This completes the fix on all the stable branches where
pg_database can use a toast table, down to 12.
Author: Ashwin Agrawal, Junfeng Yang
Discussion: https://postgr.es/m/DM5PR0501MB38800D9E4605BCA72DD35557CCE10@DM5PR0501MB3880.namprd05.prod.outlook.com
Discussion: https://postgr.es/m/Y70XNVbUWQsR2Car@paquier.xyz
Backpatch-through: 12
M src/backend/access/heap/heapam.c
M src/backend/commands/vacuum.c
Fix tab completion of ALTER FUNCTION/PROCEDURE/ROUTINE ... SET SCHEMA.
commit : 2ad4abedfeec23098c8066cf177216238224a60a
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 6 Jan 2023 11:13:34 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 6 Jan 2023 11:13:34 +0000
The ALTER DATABASE|FUNCTION|PROCEDURE|ROLE|ROUTINE|USER ... SET <name>
case in psql tab completion failed to exclude <name> = "SCHEMA", which
caused ALTER FUNCTION|PROCEDURE|ROUTINE ... SET SCHEMA to complete
with "FROM CURRENT" and "TO", which won't work.
Fix that, so that those cases now complete with the list of schemas,
like other ALTER ... SET SCHEMA commands.
Noticed while testing the recent patch to improve tab completion for
ALTER FUNCTION/PROCEDURE/ROUTINE, but this is not directly related to
that patch. Rather, this is a long-standing bug, so back-patch to all
supported branches.
Discussion: https://postgr.es/m/CALDaNm0s7GQmkLP_mx5Cvk=UzYMnjhPmXBxU8DsHEunFbC5sTg@mail.gmail.com
M src/bin/psql/tab-complete.c
Fix calculation of which GENERATED columns need to be updated.
commit : ad38e2f89116435cffd56507380d94e4eb588789
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 Jan 2023 14:12:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 Jan 2023 14:12:17 -0500
We were identifying the updatable generated columns of inheritance
children by transposing the calculation made for their parent.
However, there's nothing that says a traditional-inheritance child
can't have generated columns that aren't there in its parent, or that
have different dependencies than are in the parent's expression.
(At present it seems that we don't enforce that for partitioning
either, which is likely wrong to some degree or other; but the case
clearly needs to be handled with traditional inheritance.)
Hence, drop the very-klugy-anyway "extraUpdatedCols" RTE field
in favor of identifying which generated columns depend on updated
columns during executor startup. In HEAD we can remove
extraUpdatedCols altogether; in back branches, it's still there but
always empty. Another difference between the HEAD and back-branch
versions of this patch is that in HEAD we can add the new bitmap field
to ResultRelInfo, but that would cause an ABI break in back branches.
Like 4b3e37993, add a List field at the end of struct EState instead.
Back-patch to v13. The bogus calculation is also being made in v12,
but it doesn't have the same visible effect because we don't use it
to decide which generated columns to recalculate; as a consequence of
which the patch doesn't apply easily. I think that there might still
be a demonstrable bug associated with trigger firing conditions, but
that's such a weird corner-case usage that I'm content to leave it
unfixed in v12.
Amit Langote and Tom Lane
Discussion: https://postgr.es/m/CA+HiwqFshLKNvQUd1DgwJ-7tsTp=dwv7KZqXC4j2wYBV1aCDUA@mail.gmail.com
Discussion: https://postgr.es/m/2793383.1672944799@sss.pgh.pa.us
M contrib/postgres_fdw/postgres_fdw.c
M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/backend/optimizer/util/inherit.c
M src/backend/optimizer/util/plancat.c
M src/backend/replication/logical/worker.c
M src/backend/rewrite/rewriteHandler.c
M src/include/nodes/execnodes.h
M src/include/nodes/parsenodes.h
M src/include/optimizer/inherit.h
M src/include/optimizer/plancat.h
M src/include/rewrite/rewriteHandler.h
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql
Improve documentation of the CREATEROLE attibute.
commit : 5dac191edf1816860993e5f43b817eafcece1166
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 3 Jan 2023 14:50:40 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 3 Jan 2023 14:50:40 -0500
In user-manag.sgml, document precisely what privileges are conveyed
by CREATEROLE. Make particular note of the fact that it allows
changing passwords and granting access to high-privilege roles.
Also remove the suggestion of using a user with CREATEROLE and
CREATEDB instead of a superuser, as there is no real security
advantage to this approach.
Elsewhere in the documentation, adjust text that suggests that
<literal>CREATEROLE</literal> only allows for role creation, and
refer to the documentation in user-manag.sgml as appropriate.
Patch by me, reviewed by Álvaro Herrera
Discussion: http://postgr.es/m/CA+TgmoZBsPL8nPhvYecx7iGo5qpDRqa9k_AcaW1SbOjugAY1Ag@mail.gmail.com
M doc/src/sgml/ref/alter_role.sgml
M doc/src/sgml/ref/create_role.sgml
M doc/src/sgml/ref/createuser.sgml
M doc/src/sgml/user-manag.sgml
Fix typos in comments, code and documentation
commit : 1c89549ca48d04195bfc774534a54cf84b797e8b
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 3 Jan 2023 16:26:34 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 3 Jan 2023 16:26:34 +0900
While on it, newlines are removed from the end of two elog() strings.
The others are simple grammar mistakes. One comment in pg_upgrade
referred incorrectly to sequences since a7e5457.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20221230231257.GI1153@telsasoft.com
Backpatch-through: 11
M doc/src/sgml/parallel.sgml
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/sources.sgml
M src/backend/access/common/bufmask.c
M src/backend/access/spgist/spgutils.c
M src/backend/jit/llvm/llvmjit.c
M src/backend/optimizer/util/tlist.c
M src/backend/utils/adt/ruleutils.c
M src/bin/pg_upgrade/info.c
M src/test/regress/expected/expressions.out
M src/test/regress/sql/expressions.sql
perl: Hide warnings inside perl.h when using gcc compatible compiler
commit : ce073d01445c09733ba71010276f1ef255b89efd
author : Andres Freund <andres@anarazel.de>
date : Thu, 29 Dec 2022 12:47:29 -0800
committer: Andres Freund <andres@anarazel.de>
date : Thu, 29 Dec 2022 12:47:29 -0800
New versions of perl trigger warnings within perl.h with our compiler
flags. At least -Wdeclaration-after-statement, -Wshadow=compatible-local are
known to be problematic.
To avoid these warnings, conditionally use #pragma GCC system_header before
including plperl.h.
Alternatively, we could add the include paths for problematic headers with
-isystem, but that is a larger hammer and is harder to search for.
A more granular alternative would be to use #pragma GCC diagnostic
push/ignored/pop, but gcc warns about unknown warnings being ignored, so every
to-be-ignored-temporarily compiler warning would require its own pg_config.h
symbol and #ifdef.
As the warnings are voluminous, it makes sense to backpatch this change. But
don't do so yet, we first want gather buildfarm coverage - it's e.g. possible
that some compiler claiming to be gcc compatible has issues with the pragma.
Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: Discussion: https://postgr.es/m/20221228182455.hfdwd22zztvkojy2@awork3.anarazel.de
M src/include/c.h
M src/pl/plperl/plperl.h
Avoid reference to nonexistent array element in ExecInitAgg().
commit : 19adcaf00f7d8480f231bcfbb6b7a4401a531ce5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Jan 2023 16:17:00 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Jan 2023 16:17:00 -0500
When considering an empty grouping set, we fetched
phasedata->eqfunctions[-1]. Because the eqfunctions array is
palloc'd, that would always be an aset pointer in released versions,
and thus the code accidentally failed to malfunction (since it would
do nothing unless it found a null pointer). Nonetheless this seems
like trouble waiting to happen, so add a check for length == 0.
It's depressing that our valgrind testing did not catch this.
Maybe we should reconsider the choice to not mark that word NOACCESS?
Richard Guo
Discussion: https://postgr.es/m/CAMbWs4-vZuuPOZsKOYnSAaPYGKhmacxhki+vpOKk0O7rymccXQ@mail.gmail.com
M src/backend/executor/nodeAgg.c
Update copyright for 2023
commit : 58dcac07ed347774d0fa5cc8e47dcd8462bdf136
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Jan 2023 15:00:36 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Jan 2023 15:00:36 -0500
Backpatch-through: 11
M COPYRIGHT
M doc/src/sgml/legal.sgml
Fix event trigger example
commit : 843072e1b2c3e329d2040bb266dc4b9222d3db5f
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 23 Dec 2022 13:21:41 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 23 Dec 2022 13:21:41 +0100
Commit 2f9661311b changed command tags from strings to numbers, but
forgot to adjust the code in the event trigger example, which
consequently failed to compile.
While fixing that, improve the indentation to adhere to pgindent style.
Backpatch to v13, where the change was introduced.
Author: Laurenz Albe
Discussion: https://postgr.es/m/81e36ac17dc80489e74dc5b6914afa6ccdb1a99d.camel@cybertec.at
M doc/src/sgml/event-trigger.sgml
Fix some incorrectness in upgrade_adapt.sql on query for WITH OIDS
commit : d4fea2e89d44a0132e86a1659cf79e8c3057bb57
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 11:27:17 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 11:27:17 +0900
The query used to disable WITH OIDS in all the relations making use of
it was checking for materialized views, but this is not a supported
operation. On the contrary, this needs to be done on foreign tables.
While on it, use quote_ident() in the ALTER TABLE strings built on the
relation name.
Author: Anton A. Melnikov, Michael Paquier
Discussion: https://postgr.es/m/49f389ba-95ce-8a9b-09ae-f60650c0e7c7@inbox.ru
Backpatch-through: 12
M src/bin/pg_upgrade/upgrade_adapt.sql
Fix come incorrect elog() messages in aclchk.c
commit : 4dbe72d61ac6dc1ed4a230db2adec1dc01041f7f
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 10:04:34 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 10:04:34 +0900
Three error strings used with cache lookup failures were referring to
incorrect object types for ACL checks:
- Schemas
- Types
- Foreign Servers
There errors should never be triggered, but if they do incorrect
information would be reported.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20221222153041.GN1153@telsasoft.com
Backpatch-through: 11
M src/backend/catalog/aclchk.c
Add some recursion and looping defenses in prepjointree.c.
commit : 4fceb454f2df57f63d05ccb4a26a9f49c377f28c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2022 10:35:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2022 10:35:03 -0500
Andrey Lepikhov demonstrated a case where we spend an unreasonable
amount of time in pull_up_subqueries(). Not only is that recursing
with no explicit check for stack overrun, but the code seems not
interruptable by control-C. Let's stick a CHECK_FOR_INTERRUPTS
there, along with sprinkling some stack depth checks.
An actual fix for the excessive time consumption seems a bit
risky to back-patch; but this isn't, so let's do so.
Discussion: https://postgr.es/m/703c09a2-08f3-d2ec-b33d-dbecd62428b8@postgrespro.ru
M src/backend/optimizer/prep/prepjointree.c
Fix contrib/seg to be more wary of long input numbers.
commit : d35f1d485c392ce058382794742ce246e47643ec
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Dec 2022 17:51:50 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Dec 2022 17:51:50 -0500
seg stores the number of significant digits in an input number
in a "char" field. If char is signed, and the input is more than
127 digits long, the count can read out as negative causing
seg_out() to print garbage (or, if you're really unlucky,
even crash).
To fix, clamp the digit count to be not more than FLT_DIG.
(In theory this loses some information about what the original
input was, but it doesn't seem like useful information; it would
not survive dump/restore in any case.)
Also, in case there are stored values of the seg type containing
bad data, add a clamp in seg_out's restore() subroutine.
Per bug #17725 from Robins Tharakan. It's been like this
forever, so back-patch to all supported branches.
Discussion: https://postgr.es/m/17725-0a09313b67fbe86e@postgresql.org
M contrib/seg/expected/seg.out
M contrib/seg/seg.c
M contrib/seg/segparse.y
M contrib/seg/sql/seg.sql
Re-adjust drop-index-concurrently-1 isolation test
commit : e39856d1f027a91f20e7c8cac7a5c844b74c4962
author : David Rowley <drowley@postgresql.org>
date : Fri, 16 Dec 2022 11:41:28 +1300
committer: David Rowley <drowley@postgresql.org>
date : Fri, 16 Dec 2022 11:41:28 +1300
It seems that drop-index-concurrently-1 has started to forget what it was
originally meant to be testing. d2d8a229b, which added incremental sorts
changed the expected plan to be an Index Scan plan instead of a Seq Scan
plan. This occurred as the primary key index of the table in question
provided presorted input and, because that index happened to be the
cheapest input path due to enable_seqscan being disabled, the incremental
sort changes just added a Sort on top of that. It seems based on the name
of the PREPAREd statement that the intention here is that the query
produces a seqscan plan.
The reason this test has become broken seems to be due to how the test was
originally coded. The test was trying to force a seqscan plan by
performing some casting to make it so the test_dc index couldn't be used
to perform the required filtering. Trying to coax the planner into using
a plan which has costed in a disable_cost seems like it's always going to
be flakey as small changes in costs are drowned out by the large
disable_cost combined with add_path's STD_FUZZ_FACTOR. Here we get rid of
the casts that we're using to try to trick the planner into a seqscan and
instead toggle enable_seqscan as and when required to get the desired
plan.
Additionally, rename a few things in the test and add some additional
wording to the comments to try and make it more clear in the future what
we expect this test to be doing.
Discussion: https://postgr.es/m/CAApHDvrbDhObhLV+=U_K_-t+2Av2av1aL9d+2j_3AO-XndaviA@mail.gmail.com
Backpatch-through: 13, where d2d8a229b changed the expected test output
M src/test/isolation/expected/drop-index-concurrently-1.out
M src/test/isolation/expected/drop-index-concurrently-1_2.out
M src/test/isolation/specs/drop-index-concurrently-1.spec
Rethink handling of [Prevent|Is]InTransactionBlock in pipeline mode.
commit : 942cc240f95998793e10156952c14961b5559b2a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Dec 2022 14:23:59 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Dec 2022 14:23:59 -0500
Commits f92944137 et al. made IsInTransactionBlock() set the
XACT_FLAGS_NEEDIMMEDIATECOMMIT flag before returning "false",
on the grounds that that kept its API promises equivalent to those of
PreventInTransactionBlock(). This turns out to be a bad idea though,
because it allows an ANALYZE in a pipelined series of commands to
cause an immediate commit, which is unexpected.
Furthermore, if we return "false" then we have another issue,
which is that ANALYZE will decide it's allowed to do internal
commit-and-start-transaction sequences, thus possibly unexpectedly
committing the effects of previous commands in the pipeline.
To fix the latter situation, invent another transaction state flag
XACT_FLAGS_PIPELINING, which explicitly records the fact that we
have executed some extended-protocol command and not yet seen a
commit for it. Then, require that flag to not be set before allowing
InTransactionBlock() to return "false".
Having done that, we can remove its setting of NEEDIMMEDIATECOMMIT
without fear of causing problems. This means that the API guarantees
of IsInTransactionBlock now diverge from PreventInTransactionBlock,
which is mildly annoying, but it seems OK given the very limited usage
of IsInTransactionBlock. (In any case, a caller preferring the old
behavior could always set NEEDIMMEDIATECOMMIT for itself.)
For consistency also require XACT_FLAGS_PIPELINING to not be set
in PreventInTransactionBlock. This too is meant to prevent commands
such as CREATE DATABASE from silently committing previous commands
in a pipeline.
Per report from Peter Eisentraut. As before, back-patch to all
supported branches (which sadly no longer includes v10).
Discussion: https://postgr.es/m/65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com
M doc/src/sgml/protocol.sgml
M src/backend/access/transam/xact.c
M src/backend/tcop/postgres.c
M src/include/access/xact.h
doc: Add missing <varlistentry> markups for developer GUCs
commit : 84e6188d68f421523f4a25e9132e8e4fa9700648
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 5 Dec 2022 11:23:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 5 Dec 2022 11:23:33 +0900
Missing such markups makes it impossible to create links back to these
GUCs, and all the other parameters have one already.
Author: Ian Lawrence Barwick
Discussion: https://postgr.es/m/CAB8KJ=jx=6dFB_EN3j0UkuvG3cPu5OmQiM-ZKRAz+fKvS+u8Ng@mail.gmail.com
Backpatch-through: 11
M doc/src/sgml/config.sgml
Fix generate_partitionwise_join_paths() to tolerate failure.
commit : 4ebca555cf238628b933f79fd90fdd41bed4d39d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Dec 2022 13:17:18 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Dec 2022 13:17:18 -0500
We might fail to generate a partitionwise join, because
reparameterize_path_by_child() does not support all path types.
This should not be a hard failure condition: we should just fall back
to a non-partitioned join. However, generate_partitionwise_join_paths
did not consider this possibility and would emit the (misleading)
error "could not devise a query plan for the given query" if we'd
failed to make any paths for a child join. Fix it to give up on
partitionwise joining if so. (The accepted technique for giving up
appears to be to set rel->nparts = 0, which I find pretty bizarre,
but there you have it.)
I have not added a test case because there'd be little point:
any omissions of this sort that we identify would soon get fixed
by extending reparameterize_path_by_child(), so the test would stop
proving anything. However, right now there is a known test case based
on failure to cover MaterialPath, and with that I've found that this
is broken in all supported versions. Hence, patch all the way back.
Original report and patch by me; thanks to Richard Guo for
identifying a test case that works against committed versions.
Discussion: https://postgr.es/m/1854233.1669949723@sss.pgh.pa.us
M src/backend/optimizer/path/allpaths.c
Fix DEFAULT handling for multi-row INSERT rules.
commit : 3bed881237b1b5694d525da7c8974e09198d445f
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 3 Dec 2022 12:17:47 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 3 Dec 2022 12:17:47 +0000
When updating a relation with a rule whose action performed an INSERT
from a multi-row VALUES list, the rewriter might skip processing the
VALUES list, and therefore fail to replace any DEFAULTs in it. This
would lead to an "unrecognized node type" error.
The reason was that RewriteQuery() assumed that a query doing an
INSERT from a multi-row VALUES list would necessarily only have one
item in its fromlist, pointing to the VALUES RTE to read from. That
assumption is correct for the original query, but not for product
queries produced for rule actions. In such cases, there may be
multiple items in the fromlist, possibly including multiple VALUES
RTEs.
What is required instead is for RewriteQuery() to skip any RTEs from
the product query's originating query, which might include one or more
already-processed VALUES RTEs. What's left should then include at most
one VALUES RTE (from the rule action) to be processed.
Patch by me. Thanks to Tom Lane for reviewing.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAEZATCV39OOW7LAR_Xq4i%2BLc1Byux%3DeK3Q%3DHD_pF1o9LBt%3DphA%40mail.gmail.com
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql
Prevent pgstats from getting confused when relkind of a relation changes
commit : 7944d2d8c78b190908e99b4dc1719d7dca83091b
author : Andres Freund <andres@anarazel.de>
date : Fri, 2 Dec 2022 17:50:26 -0800
committer: Andres Freund <andres@anarazel.de>
date : Fri, 2 Dec 2022 17:50:26 -0800
When the relkind of a relache entry changes, because a table is converted into
a view, pgstats can get confused in 15+, leading to crashes or assertion
failures.
For HEAD, Tom fixed this in b23cd185fd5, by removing support for converting a
table to a view, removing the source of the inconsistency. This commit just
adds an assertion that a relcache entry's relkind does not change, just in
case we end up with another case of that in the future. As there's no cases of
changing relkind anymore, we can't add a test that that's handled correctly.
For 15, fix the problem by not maintaining the association with the old pgstat
entry when the relkind changes during a relcache invalidation processing. In
that case the pgstat entry needs to be unlinked first, to avoid
PgStat_TableStatus->relation getting out of sync. Also add a test reproducing
the issues.
No known problem exists in 11-14, so just add the test there.
Reported-by: vignesh C <vignesh21@gmail.com>
Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CALDaNm2yXz+zOtv7y5zBd5WKT8O0Ld3YxikuU3dcyCvxF7gypA@mail.gmail.com
Discussion: https://postgr.es/m/CALDaNm3oZA-8Wbps2Jd1g5_Gjrr-x3YWrJPek-mF5Asrrvz2Dg@mail.gmail.com
Backpatch: 15-
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
Fix memory leak for hashing with nondeterministic collations.
commit : a844052b5d97c351ba800e51e37b833f93863c29
author : Jeff Davis <jdavis@postgresql.org>
date : Thu, 1 Dec 2022 11:26:32 -0800
committer: Jeff Davis <jdavis@postgresql.org>
date : Thu, 1 Dec 2022 11:26:32 -0800
Backpatch through 12, where nondeterministic collations were
introduced (5e1963fb76).
Backpatch-through: 12
M src/backend/access/hash/hashfunc.c
M src/backend/utils/adt/varchar.c
Doc: add example of round(v, s) with negative s.
commit : a475157e6bf0c0f509cc9fb6ccff2b3876eb5f4b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Dec 2022 12:26:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Dec 2022 12:26:12 -0500
This has always worked, but you'd be unlikely to guess it
from the documentation. Add an example showing it.
Lack of docs noted by David Johnston. Back-patch to v13;
the documentation layout we used before that was not very
amenable to squeezing in multiple examples.
Discussion: https://postgr.es/m/CAKFQuwZ4Vy1Xty0G5Ok+ot=NDrU3C6hzF1JwUk-FEkwe3V9_RA@mail.gmail.com
M doc/src/sgml/func.sgml
revert: add transaction processing chapter with internals info
commit : 312061cbc76e1a1f3244f89697c4078bc3e8523c
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 1 Dec 2022 10:45:08 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 1 Dec 2022 10:45:08 -0500
This doc patch (master hash 66bc9d2d3e) was decided to be too
significant for backpatching, so reverted in all but master. Also fix
SGML file header comment in master.
Reported-by: Peter Eisentraut
Discussion: https://postgr.es/m/c6304b19-6ff7-f3af-0148-cf7aa7e2fbfd@enterprisedb.com
Backpatch-through: 11
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/datatype.sgml
M doc/src/sgml/filelist.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/glossary.sgml
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/pgrowlocks.sgml
M doc/src/sgml/postgres.sgml
M doc/src/sgml/ref/release_savepoint.sgml
M doc/src/sgml/ref/rollback.sgml
M doc/src/sgml/ref/rollback_to.sgml
M doc/src/sgml/wal.sgml
D doc/src/sgml/xact.sgml
Reject missing database name in pg_regress and cohorts.
commit : ae9939020dda40af579678489b11ef20fe3cca05
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Nov 2022 13:01:41 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Nov 2022 13:01:41 -0500
Writing "pg_regress --dbname= ..." led to a crash, because
we weren't expecting there to be no database name supplied.
It doesn't seem like a great idea to run regression tests
in whatever is the user's default database; so rather than
supporting this case let's explicitly reject it.
Per report from Xing Guo. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/CACpMh+A8cRvtvtOWVAZsCM1DU81GK4DL26R83y6ugZ1osV=ifA@mail.gmail.com
M src/test/regress/pg_regress.c
doc: add transaction processing chapter with internals info
commit : 4df5462f345b5e50cedf42300cad8616c7df3f6d
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 29 Nov 2022 20:49:52 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 29 Nov 2022 20:49:52 -0500
This also adds references to this new chapter at relevant sections of
our documentation. Previously much of these internal details were
exposed to users, but not explained. This also updates RELEASE
SAVEPOINT.
Discussion: https://postgr.es/m/CANbhV-E_iy9fmrErxrCh8TZTyenpfo72Hf_XD2HLDppva4dUNA@mail.gmail.com
Author: Simon Riggs, Laurenz Albe
Reviewed-by: Bruce Momjian
Backpatch-through: 11
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/datatype.sgml
M doc/src/sgml/filelist.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/glossary.sgml
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/pgrowlocks.sgml
M doc/src/sgml/postgres.sgml
M doc/src/sgml/ref/release_savepoint.sgml
M doc/src/sgml/ref/rollback.sgml
M doc/src/sgml/ref/rollback_to.sgml
M doc/src/sgml/wal.sgml
A doc/src/sgml/xact.sgml
Fix comment in fe-auth-scram.c
commit : 4c7bb4dccb49379d891853ebd99ade7002843f96
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 30 Nov 2022 08:38:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 30 Nov 2022 08:38:33 +0900
The frontend-side routine in charge of building a SCRAM verifier
mentioned that the restrictions applying to SASLprep on the password
with the encoding are described at the top of fe-auth-scram.c, but this
information is in auth-scram.c.
This is wrong since 8f8b9be, so backpatch all the way down as this is an
important documentation bit.
Spotted while reviewing a different patch.
Backpatch-through: 11
M src/interfaces/libpq/fe-auth-scram.c
Improve heuristics for compressing the KnownAssignedXids array.
commit : 6e8ad11521cccda7dad29f3e6750eb0b9be46527
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2022 15:43:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2022 15:43:17 -0500
Previously, we'd compress only when the active range of array entries
reached Max(4 * PROCARRAY_MAXPROCS, 2 * pArray->numKnownAssignedXids).
If max_connections is large, the first term could result in not
compressing for a long time, resulting in much wastage of cycles in
hot-standby backends scanning the array to take snapshots. Get rid
of that term, and just bound it to 2 * pArray->numKnownAssignedXids.
That however creates the opposite risk, that we might spend too much
effort compressing. Hence, consider compressing only once every 128
commit records. (This frequency was chosen by benchmarking. While
we only tried one benchmark scenario, the results seem stable over
a fairly wide range of frequencies.)
Also, force compression when processing RecoveryInfo WAL records
(which should be infrequent); the old code could perform compression
then, but would do so only after the same array-range check as for
the transaction-commit path.
Also, opportunistically run compression if the startup process is about
to wait for WAL, though not oftener than once a second. This should
prevent cases where we waste lots of time by leaving the array
not-compressed for long intervals due to low WAL traffic.
Lastly, add a simple check to keep us from uselessly compressing
when the array storage is already compact.
Back-patch, as the performance problem is worse in pre-v14 branches
than in HEAD.
Simon Riggs and Michail Nikolaev, with help from Tom Lane and
Andres Freund.
Discussion: https://postgr.es/m/CALdSSPgahNUD_=pB_j=1zSnDBaiOtqVfzo8Ejt5J_k7qZiU1Tw@mail.gmail.com
M src/backend/access/transam/xlog.c
M src/backend/storage/ipc/procarray.c
M src/include/storage/procarray.h
Remove bogus Assert and dead code in remove_useless_results_recurse().
commit : aca695fb6847638538833821ebab8a62d51c4549
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2022 10:52:44 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2022 10:52:44 -0500
The JOIN_SEMI case Assert'ed that there are no PlaceHolderVars that
need to be evaluated at the semijoin's RHS, which is wrong because
there could be some in the semijoin's qual condition. However, there
could not be any references further up than that, and within the qual
there is not any way that such a PHV could have gone to null yet, so
we don't really need the PHV and there is no need to avoid making the
RHS-removal optimization. The upshot is that there's no actual bug
in production code, and we ought to just remove this misguided Assert.
While we're here, also drop the JOIN_RIGHT case, which is dead code
because reduce_outer_joins() already got rid of JOIN_RIGHT.
Per bug #17700 from Xin Wen. Uselessness of the JOIN_RIGHT case
pointed out by Richard Guo. Back-patch to v12 where this code
was added.
Discussion: https://postgr.es/m/17700-2b5c10d917c30687@postgresql.org
M src/backend/optimizer/prep/prepjointree.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix binary mismatch for MSVC plperl vs gcc built perl libs
commit : 68d89d80c3db06ad080a0f291e165456fb2f51f7
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
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 : a2dcd78dd0837c5b705569f99d86ebf0d5a5725f
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
Another oversight in 9b4eafcaf.
M GNUmakefile.in
Add portlock directory to .gitignore
commit : 46d724107b5527b1b94e15358acd1bf030dd70c4
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
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 : 9fe5cff141388316779bcc6662ca2d2cd0e53872
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
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 : 4ec157c15067be979d271416dacf86a5fce34cbc
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 25 Nov 2022 09:15:31 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 25 Nov 2022 09:15:31 +0530
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 : 5a185246f9a742371a75ac0e3a95d0ceba9494e5
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
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 : f4b777e77dbc46b657bd3ea331ba9f14fe4d34c9
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
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 : 6e639267a5346c169a77b4ec3b14de8da2ddce8c
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
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 : 4b9013d64f231ddbadd2b06cf75499c8e8cd4cc1
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
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
Ignore invalidated slots while computing oldest catalog Xmin
commit : 36eeb37cd611c0a0bfb5743d9ddbef8f04fc87f3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 22 Nov 2022 10:56:07 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 22 Nov 2022 10:56:07 +0100
Once a logical slot has acquired a catalog_xmin, it doesn't let go of
it, even when invalidated by exceeding the max_slot_wal_keep_size, which
means that dead catalog tuples are not removed by vacuum anymore since
the point is invalidated, until the slot is dropped. This could be
catastrophic if catalog churn is high.
Change the computation of Xmin to ignore invalidated slots,
to prevent dead rows from accumulating.
Backpatch to 13, where slot invalidation appeared.
Author: Sirisha Chamarthi <sirichamarthi22@gmail.com>
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Discussion: https://postgr.es/m/CAKrAKeUEDeqquN9vwzNeG-CN8wuVsfRYbeOUV9qKO_RHok=j+g@mail.gmail.com
M src/backend/replication/slot.c
M src/backend/storage/ipc/procarray.c
Replace link to Hunspell with the current homepage
commit : 0e3215292f48f3e204402a07140322b63a30de36
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
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 : 74670688faaec94d9177ac182c5516c5f1a7bb9c
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
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
Fix mislabeling of PROC_QUEUE->links as PGPROC, fixing UBSan on 32bit
commit : c13667b518e3ff21fd756b571302acd6f8688e45
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
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 : d3d388831d8819dbf415d2cddadded9f9c4135bd
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
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 : a5b26aaafe4fc4ee96d09103e2692b743850c1a6
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
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 : e46e986baef04b9127a991f8a08d5c057671cb45
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
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 : 9a299cf7c21f30ca5d045faaf725e8216d3cc5f5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Nov 2022 16:54:30 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Nov 2022 16:54:30 -0500
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_handler.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/access/table/tableam.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 : d419d391fc215cd682953394bb8e2a48bd7deb7b
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
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 : 20c22333630111718bc97ce9a19b392f23e3c525
author : Amit Kapila <akapila@postgresql.org>
date : Mon, 14 Nov 2022 10:11:10 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Mon, 14 Nov 2022 10:11:10 +0530
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 : 58a45bb1d82b90e33a45b646717bf6a035256ded
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
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 : 294a2199a331ff719e0d0fe70fd2b6200689eb16
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
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
Re-allow building on Microsoft Visual Studio 2013.
commit : 0942acb73efcff1564f8d1b1ae890c8135467eae
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Nov 2022 10:23:49 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Nov 2022 10:23:49 -0500
In commit 450ee7012 I supposed that all platforms we now care about have
snprintf(), since that's required by C99. Turns out that Microsoft did
not get around to adding that until VS2015. We've dropped support for
VS2013 as of HEAD (cf 6203583b7), but not in the back branches, so add
a hack for this in the back branches only.
There's no easy shortcut to an exact emulation of standard snprintf
in VS2013, but fortunately we don't need one: this code was just fine
with using sprintf before 450ee7012, so we can make it do so again
on that platform (and any others where the problem might crop up).
Per bug #17681 from Daisuke Higuchi. Back-patch to v12, like the
previous patch.
Discussion: https://postgr.es/m/17681-485ba2ec13e7f392@postgresql.org
M src/port/snprintf.c
Doc: add comments about PreventInTransactionBlock/IsInTransactionBlock.
commit : 1949135e79e852e19958873203bf32691754faaa
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
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 : c304c069d14805b1e2e034ec01236077139091cf
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 9 Nov 2022 09:39:53 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 9 Nov 2022 09:39:53 +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/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 : 2dca4d38c0b7025bf48db13727360177dd64c570
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
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
Stamp 13.9.
commit : b664e3552b800b480e2b4fadd847f8b312e00642
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Nov 2022 16:45:38 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Nov 2022 16:45:38 -0500
M configure
M configure.in
Translation updates
commit : 5680c5de322de1d7c0a7c657231bc252e5c471ef
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 7 Nov 2022 13:57:17 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 7 Nov 2022 13:57:17 +0100
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 93ab2efcf9d6fb34739c57e61d57ae37e1fb03d3
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/ru.po
M src/bin/pg_archivecleanup/po/es.po
M src/bin/pg_archivecleanup/po/ru.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_checksums/po/es.po
M src/bin/pg_checksums/po/ru.po
M src/bin/pg_config/po/es.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/ja.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_resetwal/po/es.po
M src/bin/pg_resetwal/po/ru.po
M src/bin/pg_rewind/po/es.po
M src/bin/pg_test_fsync/po/es.po
M src/bin/pg_test_fsync/po/ru.po
M src/bin/pg_test_timing/po/es.po
M src/bin/pg_upgrade/po/es.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_verifybackup/po/es.po
M src/bin/pg_verifybackup/po/ru.po
M src/bin/pg_waldump/po/de.po
M src/bin/pg_waldump/po/es.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_waldump/po/ru.po
M src/bin/pg_waldump/po/sv.po
M src/bin/psql/po/es.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/ru.po
Release notes for 15.1, 14.6, 13.9, 12.13, 11.18, 10.23.
commit : a0397cca6f32e879b3d11e09f5115c13c389014f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Nov 2022 11:07:28 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Nov 2022 11:07:28 -0500
M doc/src/sgml/release-13.sgml
Correct error message for row-level triggers with transition tables on partitioned tables.
commit : 26c1cab4c9fafd5cf7c39d42790d3ca9a3e4688a
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 4 Nov 2022 19:15:04 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 4 Nov 2022 19:15:04 +0900
"Triggers on partitioned tables cannot have transition tables." is
incorrect as we allow statement-level triggers on partitioned tables to
have transition tables.
This has been wrong since commit 86f575948; back-patch to v11 where that
commit came in.
Reviewed by Tom Lane.
Discussion: https://postgr.es/m/CAPmGK17gk4vXLzz2iG%2BG4LWRWCoVyam70nZ3OuGm1hMJwDrhcg%40mail.gmail.com
M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
Create FKs properly when attaching table as partition
commit : 41b6e7c9a32e16f134622663e77060541c0e46a9
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 3 Nov 2022 20:40:21 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 3 Nov 2022 20:40:21 +0100
Commit f56f8f8da6af added some code in CloneFkReferencing that's way too
lax about a Constraint node it manufactures, not initializing enough
struct members -- initially_valid in particular was forgotten. This
causes some FKs in partitions added by ALTER TABLE ATTACH PARTITION to
be marked as not validated. Set initially_valid true, which fixes the
bug.
While at it, make the struct initialization more complete. Very similar
code was added in two other places by the same commit; make them all
follow the same pattern for consistency, though no bugs are apparent
there.
This bug has never been reported: I only happened to notice while
working on commit 614a406b4ff1. The test case that was added there with
the improper result is repaired.
Backpatch to 12.
Discussion: https://postgr.es/m/20221005105523.bhuhkdx4olajboof@alvherre.pgsql
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
Avoid crash after function syntax error in a replication worker.
commit : b00f342ea0f01c3964491108dc4428838ffc269e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Nov 2022 12:01:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Nov 2022 12:01:57 -0400
If a syntax error occurred in a SQL-language or PL/pgSQL-language
CREATE FUNCTION or DO command executed in a logical replication worker,
we'd suffer a null pointer dereference or assertion failure. That
seems like a rather contrived case, but nonetheless worth fixing.
The cause is that function_parse_error_transpose assumes it must be
executing within the context of a Portal, but logical/worker.c
doesn't create a Portal since it's not running the standard executor.
We can just back off the hard Assert check and make it fail gracefully
if there's not an ActivePortal. (I have a feeling that the aggressive
check here was my fault originally, probably because I wasn't sure if
the case would always hold and wanted to find out. Well, now we know.)
The hazard seems to exist in all branches that have logical replication,
so back-patch to v10.
Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane
Discussion: https://postgr.es/m/b570c367-ba38-95f3-f62d-5f59b9808226@inbox.ru
Discussion: https://postgr.es/m/adf0452f-8c6b-7def-d35e-ab516c80088e@inbox.ru
M src/backend/catalog/pg_proc.c
Add casts to simplehash.h to silence C++ warnings.
commit : 50467082c9d44c1cb7d8fc105f65c37338d9a5a0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Nov 2022 10:47:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Nov 2022 10:47:31 -0400
Casting the result of palloc etc. to the intended type is more per
project style anyway.
(The fact that cpluspluscheck doesn't notice these problems is
because it doesn't expand any macros, which seems like a troubling
shortcoming. Don't have a good idea about improving that.)
Back-patch to v13, which is as far as the patch applies cleanly;
doesn't seem worth working harder.
David Geier
Discussion: https://postgr.es/m/aa5d88a3-71f4-3455-11cf-82de0372c941@gmail.com
M src/include/lib/simplehash.h
Allow use of __sync_lock_test_and_set for spinlocks on any machine.
commit : c479492c04eeec0ae1bce270b2bb21851add8a78
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Nov 2022 17:37:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Nov 2022 17:37:26 -0400
If we have no special-case code in s_lock.h for the current platform,
but the compiler has __sync_lock_test_and_set, use that instead of
failing. It's unlikely that anybody's __sync_lock_test_and_set
would be so awful as to be worse than our semaphore-based fallback,
but if it is, they can (continue to) use --disable-spinlocks.
This allows removal of the RISC-V special case installed by commit
c32fcac56, which generated exactly the same code but only on that
platform. Usefully, the RISC-V buildfarm animals should now test
at least the int variant of this patch.
I've manually tested both variants on ARM by dint of removing the
ARM-specific stanza. We don't want to drop that, because it already
has some special knowledge and is likely to grow more over time.
Likewise, this is not meant to preclude installing special cases
for other arches if that proves worthwhile.
Per discussion of a request to install the same code for loongarch64.
Like the previous patch, we might as well back-patch to supported
branches.
Discussion: https://postgr.es/m/761ac43d44b84d679ba803c2bd947cc0@HSMAILSVR04.hs.handsome.com.cn
M src/include/storage/s_lock.h
Defend against unsupported partition relkind in logical replication worker.
commit : 4d3f7e75c8a37a978cbeabf8e5a8b38d976c23ba
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Nov 2022 12:29:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Nov 2022 12:29:39 -0400
Since partitions can be foreign tables not only plain tables, but
logical replication only supports plain tables, we'd better check the
relkind of a partition after we find it. (There was some discussion
of checking this when adding a partitioned table to a subscription;
but that would be inadequate since the troublesome partition could be
added later.) Without this, the situation leads to a segfault or
assertion failure.
In passing, add a separate variable for the target Relation of
a cross-partition UPDATE; reusing partrel seemed mighty confusing
and error-prone.
Shi Yu and Tom Lane, per report from Ilya Gladyshev. Back-patch
to v13 where logical replication into partitioned tables became
a thing.
Discussion: https://postgr.es/m/6b93e3748ba43298694f376ca8797279d7945e29.camel@gmail.com
M src/backend/replication/logical/worker.c
Fix copy-and-pasteo in comment.
commit : 197cbca6bc7766aba215f34cb835306f101997b2
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 2 Nov 2022 18:15:05 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 2 Nov 2022 18:15:05 +0900
M src/backend/executor/nodeModifyTable.c
Update time zone data files to tzdata release 2022f.
commit : ebf48810b40bb193fd898802cf383ad92677c4a9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Nov 2022 17:08:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Nov 2022 17:08:28 -0400
DST law changes in Chile, Fiji, Iran, Jordan, Mexico, Palestine,
and Syria. Historical corrections for Chile, Crimea, Iran, and
Mexico.
Also, the Europe/Kiev zone has been renamed to Europe/Kyiv
(retaining the old name as a link).
The following zones have been merged into nearby, more-populous zones
whose clocks have agreed since 1970: Antarctica/Vostok, Asia/Brunei,
Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam,
Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo,
Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen,
Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti,
Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake and Pacific/Wallis.
(This indirectly affects zones that were already links to one of
these: Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland,
Pacific/Ponape, Pacific/Truk, and Pacific/Yap.) America/Nipigon,
America/Rainy_River, America/Thunder_Bay, Europe/Uzhgorod, and
Europe/Zaporozhye were also merged into nearby zones after discovering
that their claimed post-1970 differences from those zones seem to have
been errors.
While the IANA crew have been working on merging zones that have no
post-1970 differences for some time, this batch of changes affects
some zones that are significantly more populous than those merged
in the past, notably parts of Europe. The loss of pre-1970 timezone
history for those zones may be troublesome for applications
expecting consistency of timestamptz display. As an example, the
stored value '1944-06-01 12:00 UTC' would previously display as
'1944-06-01 13:00:00+01' if the Europe/Stockholm zone is selected,
but now it will read out as '1944-06-01 14:00:00+02'.
There exists a "packrat" option that will build the timezone data
files with this old data preserved, but the problem is that it also
resurrects a bunch of other, far less well-attested data; so much so
that actually more zones' contents change from 2022a with that option
than without it. I have chosen not to do that here, for that reason
and because it appears that no major OS distributions are using the
"packrat" option, so that doing so would cause Postgres' behavior
to diverge significantly depending on whether it was built with
--with-system-tzdata. However, for anyone for whom these changes pose
significant problems, there is a solution: build a set of timezone
files with the "packrat" option and use those with Postgres.
M src/timezone/data/tzdata.zi
pg_stat_statements: fetch stmt location/length before it disappears.
commit : a9fdb48b737d8335ea8cbb5b5b76c8187397824e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Nov 2022 12:48:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Nov 2022 12:48:01 -0400
When executing a utility statement, we must fetch everything
we need out of the PlannedStmt data structure before calling
standard_ProcessUtility. In certain cases (possibly only ROLLBACK
in extended query protocol), that data structure will get freed
during command execution. The situation is probably often harmless
in production builds, but in debug builds we intentionally overwrite
the freed memory with garbage, leading to picking up garbage values
of statement location and length, typically causing an assertion
failure later in pg_stat_statements. In non-debug builds, if
something did go wrong it would likely lead to storing garbage
for the query string.
Report and fix by zhaoqigui (with cosmetic adjustments by me).
It's an old problem, so back-patch to all supported versions.
Discussion: https://postgr.es/m/17663-a344fd0675f92128@postgresql.org
Discussion: https://postgr.es/m/1667307420050.56657@hundsun.com
M contrib/pg_stat_statements/pg_stat_statements.c
Fix ordering issue with WAL operations in GIN fast insert path
commit : 594b97509e49e30a9f6ada09110405663a2e1d6f
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 26 Oct 2022 09:41:22 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 26 Oct 2022 09:41:22 +0900
Contrary to what is documented in src/backend/access/transam/README,
ginHeapTupleFastInsert() had a few ordering issues with the way it does
its WAL operations when inserting items in its fast path.
First, when using a separate list, XLogBeginInsert() was being always
called before START_CRIT_SECTION(), and in this case a second thing was
wrong when merging lists, as an exclusive lock was taken on the tail
page *before* calling XLogBeginInsert(). Finally, when inserting items
into a tail page, the order of XLogBeginInsert() and
START_CRIT_SECTION() was reversed. This commit addresses all these
issues by moving the calls of XLogBeginInsert() after all the pages
logged are locked and pinned, within a critical section.
This has been applied first only on HEAD as of 56b6625, but as per
discussion with Tom Lane and Álvaro Herrera, a backpatch is preferred to
keep all the branches consistent and to respect the transam's README
where we can.
Author: Matthias van de Meent, Zhang Mingli
Discussion: https://postgr.es/m/CAEze2WhL8uLMqynnnCu1LAPwxD5RKEo0nHV+eXGg_N6ELU88HQ@mail.gmail.com
Backpatch-through: 10
M src/backend/access/gin/ginfast.c
pg_basebackup: Fix cross-platform tablespace relocation.
commit : 0bf2cd1602b12fef2af74e1bd8b097cf8319ee66
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 21 Oct 2022 08:21:55 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 21 Oct 2022 08:21:55 -0400
Specifically, when pg_basebackup is invoked with -Tx=y, don't error
out if x could plausibly be an absolute path either on Windows or on
non-Windows systems. We don't know whether the remote system is
running the same OS as the local system, so it's not appropriate to
assume that our local rule about absolute pathnames is the same as
the rule on the remote system.
Patch by me, reviewed by Tom Lane, Andrew Dunstan, and
Davinder Singh.
Discussion: http://postgr.es/m/CA+TgmoY+jC3YiskomvYKDPK3FbrmsDU7_8+wMHt02HOdJeRb0g@mail.gmail.com
M src/bin/pg_basebackup/pg_basebackup.c
M src/include/port.h
Add CHECK_FOR_INTERRUPTS while restoring changes during decoding.
commit : 1eed947f9852de4bd378aa0f5006a4bb8db67c09
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 21 Oct 2022 12:22:47 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 21 Oct 2022 12:22:47 +0530
Previously in commit 42681dffaf, we added CFI during decoding changes but
missed another similar case that can happen while restoring changes
spilled to disk back into memory in a loop.
Reported-by: Robert Haas
Author: Amit Kapila
Backpatch-through: 10
Discussion: https://postgr.es/m/CA+TgmoaLObg0QbstbC8ykDwOdD1bDkr4AbPpB=0DPgA2JW0mFg@mail.gmail.com
M src/backend/replication/logical/reorderbuffer.c
Fix executing invalidation messages generated by subtransactions during decoding.
commit : 38dbaaf273877355c2deeafa4b479d315a78196b
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 21 Oct 2022 09:42:24 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 21 Oct 2022 09:42:24 +0530
This problem has been introduced by commit 272248a0c1 where we started
assigning the subtransactions to the top-level transaction when we mark
both the top-level transaction and its subtransactions as containing
catalog changes. After we assign subtransactions to the top-level
transaction, we were not allowed to execute any invalidations associated
with it when we decide to skip the transaction.
The reason to assign the subtransactions to the top-level transaction was
to avoid the assertion failure in AssertTXNLsnOrder() as they have the
same LSN when we sometimes start accumulating transaction changes for
partial transactions after the restart. Now that with commit 64ff0fe4e8,
we skip this assertion check until we reach the LSN at which we start
decoding the contents of the transaction, so, there is no reason for such
an assignment anymore.
The assignment change was introduced in 15 and prior versions but this bug
doesn't exist in branches prior to 14 since we don't add invalidation
messages to subtransactions. We decided to backpatch through 11 for
consistency but not for 10 since its final release is near.
Reported-by: Kuroda Hayato
Author: Masahiko Sawada
Reviewed-by: Amit Kapila
Backpatch-through: 11
Discussion: https://postgr.es/m/TYAPR01MB58660803BCAA7849C8584AA4F57E9%40TYAPR01MB5866.jpnprd01.prod.outlook.com
Discussion: https://postgr.es/m/a89b46b6-0239-2fd5-71a9-b19b1f7a7145%40enterprisedb.com
M src/backend/replication/logical/snapbuild.c
Fix assertion failures while processing NEW_CID record in logical decoding.
commit : 25f7be1ca2362b317f4ad7d60de5be9e82d4f722
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 20 Oct 2022 09:25:13 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 20 Oct 2022 09:25:13 +0530
When the logical decoding restarts from NEW_CID, since there is no
association between the top transaction and its subtransaction, both are
created as top transactions and have the same LSN. This caused the
assertion failure in AssertTXNLsnOrder().
This patch skips the assertion check until we reach the LSN at which we
start decoding the contents of the transaction, specifically
start_decoding_at LSN in SnapBuild. This is okay because we don't
guarantee to make the association between top transaction and
subtransaction until we try to decode the actual contents of transaction.
The ordering of the records prior to the start_decoding_at LSN should have
been checked before the restart.
The other assertion failure is due to the reason that we forgot to track
that we have considered top-level transaction id in the list of catalog
changing transactions that were committed when one of its subtransactions
is marked as containing catalog change.
Reported-by: Tomas Vondra, Osumi Takamichi
Author: Masahiko Sawada, Kuroda Hayato
Reviewed-by: Amit Kapila, Dilip Kumar, Kuroda Hayato, Kyotaro Horiguchi, Masahiko Sawada
Backpatch-through: 10
Discussion: https://postgr.es/m/a89b46b6-0239-2fd5-71a9-b19b1f7a7145%40enterprisedb.com
Discussion: https://postgr.es/m/TYCPR01MB83733C6CEAE47D0280814D5AED7A9%40TYCPR01MB8373.jpnprd01.prod.outlook.com
M contrib/test_decoding/expected/catalog_change_snapshot.out
M contrib/test_decoding/specs/catalog_change_snapshot.spec
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
Track LLVM 15 changes.
commit : cf94cb58665a784acdf2091351b8c1ecb633263c
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 19 Oct 2022 22:38:58 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 19 Oct 2022 22:38:58 +1300
Per https://llvm.org/docs/OpaquePointers.html, support for non-opaque
pointers still exists and we can request that on our context. We have
until LLVM 16 to move to opaque pointers, a much larger change.
Back-patch to 11, where LLVM support arrived.
Author: Thomas Munro <thomas.munro@gmail.com>
Author: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/CAMHz58Sf_xncdyqsekoVsNeKcruKootLtVH6cYXVhhUR1oKPCg%40mail.gmail.com
M configure
M configure.in
M src/backend/jit/llvm/llvmjit.c
M src/backend/jit/llvm/llvmjit_inline.cpp
doc: move the mention of aggregate JSON functions up in section
commit : 9f49b15b9d9753b5140d657c96cf6a2c2973e5e6
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 17 Oct 2022 15:21:29 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 17 Oct 2022 15:21:29 -0400
It was previously easily overlooked at the end of several tables.
Reported-by: Alex Denman
Discussion: https://postgr.es/m/166335888474.659.16897487975376230364@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/func.sgml
doc: warn pg_stat_reset() can cause vacuum/analyze problems
commit : bed9bb929e026b91a0c45cbf7e4ee1a8bfaaa70b
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 17 Oct 2022 15:07:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 17 Oct 2022 15:07:03 -0400
The fix is to run ANALYZE.
Discussion: https://postgr.es/m/YzRr+ys98UzVQJvK@momjian.us,
https://postgr.es/m/flat/CAKJS1f8DTbCHf9gedU0He6ARsd58E6qOhEHM1caomqj_r9MOiQ%40mail.gmail.com,
https://postgr.es/m/CAKJS1f80o98hcfSk8j%3DfdN09S7Sjz%2BvuzhEwbyQqvHJb_sZw0g%40mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/monitoring.sgml
Reject non-ON-SELECT rules that are named "_RETURN".
commit : b21615d1e9b04d8098ec04abc32d308659085a45
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Oct 2022 12:14:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Oct 2022 12:14:39 -0400
DefineQueryRewrite() has long required that ON SELECT rules be named
"_RETURN". But we overlooked the converse case: we should forbid
non-ON-SELECT rules that are named "_RETURN". In particular this
prevents using CREATE OR REPLACE RULE to overwrite a view's _RETURN
rule with some other kind of rule, thereby breaking the view.
Per bug #17646 from Kui Liu. Back-patch to all supported branches.
Discussion: https://postgr.es/m/17646-70c93cfa40365776@postgresql.org
M src/backend/rewrite/rewriteDefine.c
Guard against table-AM-less relations in planner.
commit : 62b263bf779ed5d1ad0ae3fb0a5790f773423beb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Oct 2022 11:35:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Oct 2022 11:35:23 -0400
The executor will dump core if it's asked to execute a seqscan on
a relation having no table AM, such as a view. While that shouldn't
really happen, it's possible to get there via catalog corruption,
such as a missing ON SELECT rule. It seems worth installing a defense
against that. There are multiple plausible places for such a defense,
but I picked the planner's get_relation_info().
Per discussion of bug #17646 from Kui Liu. Back-patch to v12 where
the tableam APIs were introduced; in older versions you won't get a
SIGSEGV, so it seems less pressing.
Discussion: https://postgr.es/m/17646-70c93cfa40365776@postgresql.org
M src/backend/optimizer/util/plancat.c
Rename parser token REF to REF_P to avoid a symbol conflict.
commit : bc7a40b42eef717026d29b687157cd0af5adaadb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Oct 2022 15:27:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/1803927.1665938411@sss.pgh.pa.us
M src/backend/parser/gram.y
M src/include/parser/kwlist.h
Use libc's snprintf, not sprintf, for special cases in snprintf.c.
commit : a2acafc7be7a957e72234bb28b83a5e4d2bc019f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Oct 2022 11:47:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Oct 2022 11:47:44 -0400
snprintf.c has always fallen back on libc's *printf implementation
when printing pointers (%p) and floats. When this code originated,
we were still supporting some platforms that lacked native snprintf,
so we used sprintf for that. That's not actually unsafe in our usage,
but nonetheless builds on macOS are starting to complain about sprintf
being unconditionally deprecated; and I wouldn't be surprised if other
platforms follow suit. There seems little reason to believe that any
platform supporting C99 wouldn't have standards-compliant snprintf,
so let's just use that instead to suppress such warnings.
Back-patch to v12, which is where we started to require C99. It's
also where we started to use our snprintf.c everywhere, so this
wouldn't be enough to suppress the warning in older branches anyway
--- that is, in older branches these aren't necessarily all our
usages of libc's sprintf. It is enough in v12+ because any
deprecation annotation attached to libc's sprintf won't apply to
pg_sprintf. (Whether all our usages of pg_sprintf are adequately
safe is not a matter I intend to address here, but perhaps it could
do with some review.)
Per report from Andres Freund and local testing.
Discussion: https://postgr.es/m/20221015211955.q4cwbsfkyk3c4ty3@awork3.anarazel.de
M src/port/snprintf.c
Fix typo in CREATE PUBLICATION reference page
commit : ad81292370550d9ce1b395bdd2ec3ba0f81e5c01
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Oct 2022 13:36:14 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Oct 2022 13:36:14 +0200
While at it, simplify wording a bit.
Author: Takamichi Osumi <osumi.takamichi@fujitsu.com>
Reviewed-by: Peter Smith <smithpb2250@gmail.com>
Discussion: https://postgr.es/m/TYCPR01MB8373F93F5D094A2BE648990DED259@TYCPR01MB8373.jpnprd01.prod.outlook.com
M doc/src/sgml/ref/create_publication.sgml
Doc: improve recommended systemd unit file.
commit : de924f4bb3eb26d24c32b344ebf047f03dd1d94d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Oct 2022 10:51:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Oct 2022 10:51:11 -0400
Add
After=network-online.target
Wants=network-online.target
to the suggested unit file for starting a Postgres server.
This delays startup until the network interfaces have been
configured; without that, any attempt to bind to a specific
IP address will fail.
If listen_addresses is set to "localhost" or "*", it might be
possible to get away with the less restrictive "network.target",
but I don't think we need to get into such detail here.
Per suggestion from Pablo Federico.
Discussion: https://postgr.es/m/166552157407.591805.10036014441784710940@wrigleys.postgresql.org
M doc/src/sgml/runtime.sgml
Harden pmsignal.c against clobbered shared memory.
commit : 7442701374a448663061c493b40926c4e8d68838
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Oct 2022 18:54:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Oct 2022 18:54:31 -0400
The postmaster is not supposed to do anything that depends
fundamentally on shared memory contents, because that creates
the risk that a backend crash that trashes shared memory will
take the postmaster down with it, preventing automatic recovery.
In commit 969d7cd43 I lost sight of this principle and coded
AssignPostmasterChildSlot() in such a way that it could fail
or even crash if the shared PMSignalState structure became
corrupted. Remarkably, we've not seen field reports of such
crashes; but I managed to induce one while testing the recent
changes around palloc chunk headers.
To fix, make a semi-duplicative state array inside the postmaster
so that we need consult only local state while choosing a "child
slot" for a new backend. Ensure that other postmaster-executed
routines in pmsignal.c don't have critical dependencies on the
shared state, either. Corruption of PMSignalState might now
lead ReleasePostmasterChildSlot() to conclude that backend X
failed, when actually backend Y was the one that trashed things.
But that doesn't matter, because we'll force a cluster-wide reset
regardless.
Back-patch to all supported branches, since this is an old bug.
Discussion: https://postgr.es/m/3436789.1665187055@sss.pgh.pa.us
M src/backend/storage/ipc/pmsignal.c
Yet further fixes for multi-row VALUES lists for updatable views.
commit : 21e042b0bd47d8564f7178f72114d707cb1ceba8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Oct 2022 18:24:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Oct 2022 18:24:14 -0400
DEFAULT markers appearing in an INSERT on an updatable view
could be mis-processed if they were in a multi-row VALUES clause.
This would lead to strange errors such as "cache lookup failed
for type NNNN", or in older branches even to crashes.
The cause is that commit 41531e42d tried to re-use rewriteValuesRTE()
to remove any SetToDefault nodes (that hadn't previously been replaced
by the view's own default values) appearing in "product" queries,
that is DO ALSO queries. That's fundamentally wrong because the
DO ALSO queries might not even be INSERTs; and even if they are,
their targetlists don't necessarily match the view's column list,
so that almost all the logic in rewriteValuesRTE() is inapplicable.
What we want is a narrow focus on replacing any such nodes with NULL
constants. (That is, in this context we are interpreting the defaults
as being strictly those of the view itself; and we already replaced
any that aren't NULL.) We could add still more !force_nulls tests
to further lobotomize rewriteValuesRTE(); but it seems cleaner to
split out this case to a new function, restoring rewriteValuesRTE()
to the charter it had before.
Per bug #17633 from jiye_sw. Patch by me, but thanks to
Richard Guo and Japin Li for initial investigation.
Back-patch to all supported branches, as the previous fix was.
Discussion: https://postgr.es/m/17633-98cc85e1fa91e905@postgresql.org
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Ensure all perl test modules are installed
commit : 33d979aeecfbf0bfe3c93eb0ffecab870e909192
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 11 Oct 2022 09:56:13 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 11 Oct 2022 09:56:13 +0200
PostgreSQL::Test::Cluster and ::Utils were not being installed. This is
very hard to notice, as it only seems to affect external modules that
want to run tests from 15 back in earlier versions. Oversight in
b235d41d9646.
This applies only to branches 14 and back, because 15 had already been
made correct in commit b3b4d8e68ae8.
Discussion: https://postgr.es/m/20221010093415.poplkyn7pjeiv2y7@alvherre.pgsql
M src/test/perl/Makefile
Fix self-referencing foreign keys with partitioned tables
commit : 7d520e68ea1e38a9f7ad1d04bd5f95d53eef6cd4
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 7 Oct 2022 19:37:48 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 7 Oct 2022 19:37:48 +0200
There are a number of bugs in this area. Two of them are fixed here,
namely:
1. get_relation_idx_constraint_oid does not restrict the type of
constraint that's returned, so with sufficient bad luck it can
return the OID of a foreign key constraint. This has the effect that
a primary key in a partition can end up as a child of a foreign key,
which makes no sense (it needs to be the child of the equivalent
primary key.)
Change the API contract so that only index-backed constraints are
returned, mimicking get_constraint_index().
2. Both CloneFkReferenced and CloneFkReferencing clone a
self-referencing foreign key, so the partition ends up with
a duplicate foreign key. Change the former function to ignore such
constraints.
Add some tests to verify that things are better now. (However, these
new tests show some additional misbehavior that will be fixed later --
namely that there's a constraint marked NOT VALID.)
Backpatch to 12, where these constraints are possible at all.
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
Discussion: https://postgr.es/m/20220603154232.1715b14c@karst
M src/backend/catalog/pg_constraint.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Avoid improbable PANIC during heap_update, redux.
commit : 92941f26435ce3910bb9320fd92bda1e3dd4c6b5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Sep 2022 19:36:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Sep 2022 19:36:46 -0400
Commit 34f581c39 intended to ensure that RelationGetBufferForTuple
would acquire a visibility-map page pin in case the otherBuffer's
all-visible bit had become set since we last had lock on that page.
But I missed a case: when we're extending the relation, VM concerns
were dealt with only in the relatively-less-likely case that we
fail to conditionally lock the otherBuffer. I think I'd believed
that we couldn't need to worry about it if the conditional lock
succeeds, which is true for the target buffer; but the otherBuffer
was unlocked for awhile so its bit might be set anyway. So we need
to do the GetVisibilityMapPins dance, and then also recheck the
page's free space, in both cases.
Per report from Jaime Casanova. Back-patch to v12 as the previous
patch was (although there's still no evidence that the bug is
reachable pre-v14).
Discussion: https://postgr.es/m/E1lWLjP-00006Y-Ml@gemulon.postgresql.org
M src/backend/access/heap/hio.c
doc: Fix PQsslAttribute docs for compression
commit : a3de685013e7f3c0bf624e037a5569c0d5f8f0c2
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Fri, 30 Sep 2022 12:03:48 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Fri, 30 Sep 2022 12:03:48 +0200
The compression parameter to PQsslAttribute has never returned the
compression method used, it has always returned "on" or "off since
it was added in commit 91fa7b4719ac. Backpatch through v10.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/B9EC60EC-F665-47E8-A221-398C76E382C9@yesql.se
Backpatch-through: v10
M doc/src/sgml/libpq.sgml
doc: clarify internal behavior of RECURSIVE CTE queries
commit : ce4e8606cabe20ce62c8c9d3d34321df43f626ae
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 28 Sep 2022 13:14:38 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 28 Sep 2022 13:14:38 -0400
Reported-by: Tom Lane
Discussion: https://postgr.es/m/3976627.1662651004@sss.pgh.pa.us
Backpatch-through: 10
M doc/src/sgml/queries.sgml
revert "warn of SECURITY DEFINER schemas for non-sql_body funcs"
commit : 538c8ff2c0594e5549c54ff8b6e7129f3643f565
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 28 Sep 2022 13:05:20 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 28 Sep 2022 13:05:20 -0400
doc revert of commit 1703726488. Change was applied to irrelevant
branches, and was not detailed enough to be helpful in relevant
branches.
Reported-by: Peter Eisentraut, Noah Misch
Discussion: https://postgr.es/m/a2dc9de4-24fc-3222-87d3-0def8057d7d8@enterprisedb.com
Backpatch-through: 10
M doc/src/sgml/ref/create_function.sgml
Change some errdetail() to errdetail_internal()
commit : 1dd468c348095010e07eeb844e2e344ad63a52ef
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 28 Sep 2022 17:14:53 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 28 Sep 2022 17:14:53 +0200
This prevents marking the argument string for translation for gettext,
and it also prevents the given string (which is already translated) from
being translated at runtime.
Also, mark the strings used as arguments to check_rolespec_name for
translation.
Backpatch all the way back as appropriate. None of this is caught by
any tests (necessarily so), so I verified it manually.
M src/backend/catalog/dependency.c
M src/backend/commands/user.c
M src/backend/utils/adt/acl.c
M src/backend/utils/adt/jsonfuncs.c
M src/common/jsonapi.c
Fix tupdesc lifespan bug with AfterTriggersTableData.storeslot.
commit : 8c17c86154704a89c46c6a9575cf7d792f357c9c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Sep 2022 17:10:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Sep 2022 17:10:58 -0400
Commit 25936fd46 adjusted things so that the "storeslot" we use
for remapping trigger tuples would have adequate lifespan, but it
neglected to consider the lifespan of the tuple descriptor that
the slot depends on. It turns out that in at least some cases, the
tupdesc we are passing is a refcounted tupdesc, and the refcount for
the slot's reference can get assigned to a resource owner having
different lifespan than the slot does. That leads to an error like
"tupdesc reference 0x7fdef236a1b8 is not owned by resource owner
SubTransaction". Worse, because of a second oversight in the same
commit, we'd try to free the same tupdesc refcount again while
cleaning up after that error, leading to recursive errors and an
"ERRORDATA_STACK_SIZE exceeded" PANIC.
To fix the initial problem, let's just make a non-refcounted copy
of the tupdesc we're supposed to use. That seems likely to guard
against additional problems, since there's no strong reason for
this code to assume that what it's given is a refcounted tupdesc;
in which case there's an independent hazard of the tupdesc having
shorter lifespan than the slot does. (I didn't bother trying to
free said copy, since it should go away anyway when the (sub)
transaction context is cleaned up.)
The other issue can be fixed by making the code added to
AfterTriggerFreeQuery work like the rest of that function, ie be
sure that it doesn't try to free the same slot twice in the event
of recursive error cleanup.
While here, also clean up minor stylistic issues in the test case
added by 25936fd46: don't use "create or replace function", as any
name collision within the tests is likely to have ill effects
that that won't mask; and don't use function names as generic as
trigger_function1, especially if you're not going to drop them
at the end of the test stanza.
Per bug #17607 from Thomas Mc Kay. Back-patch to v12, as the
previous fix was.
Discussion: https://postgr.es/m/17607-bd8ccc81226f7f80@postgresql.org
M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Add missing source files to pg_waldump/nls.mk
commit : 4a9150f9762e9d0538badbe9842cce7242f30405
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 25 Sep 2022 17:48:03 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 25 Sep 2022 17:48:03 +0200
M src/bin/pg_waldump/nls.mk
Fix race condition where heap_delete() fails to pin VM page.
commit : 410c422b75ac53a4da438c1a4b0e1fa421db0d59
author : Jeff Davis <jdavis@postgresql.org>
date : Thu, 22 Sep 2022 10:58:49 -0700
committer: Jeff Davis <jdavis@postgresql.org>
date : Thu, 22 Sep 2022 10:58:49 -0700
Similar to 5f12bc94dc, the code must re-check PageIsAllVisible() after
buffer lock is re-acquired. Backpatching to the same version, 12.
Discussion: https://postgr.es/m/CAEP4nAw9jYQDKd_5Y+-s2E4YiUJq1vqiikFjYGpLShtp-K3gag@mail.gmail.com
Reported-by: Robins Tharakan
Reviewed-by: Robins Tharakan
Backpatch-through: 12
M src/backend/access/heap/heapam.c
Fix thinko in comment.
commit : 5f9dda4c0664faf36fdf931f00e2206dad2d3066
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 22 Sep 2022 15:55:05 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 22 Sep 2022 15:55:05 +0900
This comment has been wrong since its introduction in commit 0d5f05cde;
backpatch to v12 where that came in.
Discussion: https://postgr.es/m/CAPmGK14VGf-xQjGQN4o1QyAbXAaxugU5%3DqfcmTDh1iufUDnV_w%40mail.gmail.com
M src/backend/commands/copy.c
docs: Fix snapshot name in SET TRANSACTION docs.
commit : ff5d9e0a9952ba071bbe950546c929e71e7b8368
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 22 Sep 2022 12:54:26 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 22 Sep 2022 12:54:26 +0900
Commit 6c2003f8a1 changed the snapshot names mentioned in
SET TRANSACTION docs, however, there was one place that
the commit missed updating the name.
Back-patch to all supported versions.
Author: Japin Li
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/MEYP282MB1669BD4280044501165F8B07B64F9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
M doc/src/sgml/ref/set_transaction.sgml
Suppress more variable-set-but-not-used warnings from clang 15.
commit : db8e36682d9508b7cf4eb1c69522fe7f4f805086
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Sep 2022 13:52:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/514615.1663615243@sss.pgh.pa.us
M src/backend/optimizer/util/var.c
M src/backend/utils/cache/relcache.c
Disable -Wdeprecated-non-prototype in the back branches.
commit : 43f72e0f73a52f09651a96529970fd8ea75186a9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 Sep 2022 18:59:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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 : ca3b730baa1354c86bff78c246415443d4732f02
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 Sep 2022 12:04:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/514615.1663615243@sss.pgh.pa.us
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/backend/utils/adt/jsonpath_gram.y
M src/bin/pgbench/exprparse.y
Future-proof the recursion inside ExecShutdownNode().
commit : c58513f095e2ccc85ab450a57f80d3f96747f626
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Sep 2022 12:16:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Sep 2022 12:16:02 -0400
The API contract for planstate_tree_walker() callbacks is that they
take a PlanState pointer and a context pointer. Somebody figured
they could save a couple lines of code by ignoring that, and passing
ExecShutdownNode itself as the walker even though it has but one
argument. Somewhat remarkably, we've gotten away with that so far.
However, it seems clear that the upcoming C2x standard means to
forbid such cases, and compilers that actively break such code
likely won't be far behind. So spend the extra few lines of code
to do it honestly with a separate walker function.
In HEAD, we might as well go further and remove ExecShutdownNode's
useless return value. I left that as-is in back branches though,
to forestall complaints about ABI breakage.
Back-patch, with the thought that this might become of practical
importance before our stable branches are all out of service.
It doesn't seem to be fixing any live bug on any currently known
platform, however.
Discussion: https://postgr.es/m/208054.1663534665@sss.pgh.pa.us
M src/backend/executor/execProcnode.c
Make check_usermap() parameter names consistent.
commit : b7558111aba277059a22ea313107f6459fa2a9cd
author : Peter Geoghegan <pg@bowt.ie>
date : Sat, 17 Sep 2022 16:54:12 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Sat, 17 Sep 2022 16:54:12 -0700
The function has a bool argument named "case_insensitive", but that was
spelled "case_sensitive" in the declaration. Make them consistent now
to avoid confusion in the future.
Author: Peter Geoghegan <pg@bowt.ie>
Reviewed-By: Michael Paquiër <michael@paquier.xyz>
Discussion: https://postgr.es/m/CAH2-WznJt9CMM9KJTMjJh_zbL5hD9oX44qdJ4aqZtjFi-zA3Tg@mail.gmail.com
Backpatch: 10-
M src/include/libpq/hba.h
Include c.h instead of postgres.h in src/port/*p{read,write}*.c
commit : f69b8f324af5470dcece3ec7985964c4b6c94c77
author : Andres Freund <andres@anarazel.de>
date : Sat, 17 Sep 2022 09:21:59 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sat, 17 Sep 2022 09:21:59 -0700
Frontend code shouldn't include postgres.h. Some files in src/port/ need to
include postgres.h/postgres_fe.h, but these files don't.
Discussion: https://postgr.es/m/20220915022626.5xx3ccgkzpkqw5mq@awork3.anarazel.de
Backpatch: 12-, where 3fd2a7932ef introduced (some) of these files
M src/port/pread.c
M src/port/pwrite.c
Improve plpgsql's ability to handle arguments declared as RECORD.
commit : c18d946e2352e0909cdb5aa4548ebe569ebb9fcb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Sep 2022 13:23:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Sep 2022 13:23:01 -0400
Treat arguments declared as RECORD as if that were a polymorphic type
(which it is, sort of), in that we substitute the actual argument type
while forming the function cache lookup key. This allows the specific
composite type to be known in some cases where it was not before,
at the cost of making a separate function cache entry for each named
composite type that's passed to the function during a session. The
particular symptom discussed in bug #17610 could be solved in other
more-efficient ways, but only at the cost of considerable development
work, and there are other cases where we'd still fail without this.
Per bug #17610 from Martin Jurča. Back-patch to v11 where we first
allowed plpgsql functions to be declared as taking type RECORD.
Discussion: https://postgr.es/m/17610-fb1eef75bf6c2364@postgresql.org
M src/pl/plpgsql/src/expected/plpgsql_record.out
M src/pl/plpgsql/src/pl_comp.c
M src/pl/plpgsql/src/sql/plpgsql_record.sql
postgres_fdw: Avoid 'variable not found in subplan target list' error.
commit : 6749d4e8c71bac9cd06f9c923d38e34d07211f15
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 14 Sep 2022 18:45:04 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 14 Sep 2022 18:45:04 +0900
The tlist of the EvalPlanQual outer plan for a ForeignScan node is
adjusted to produce a tuple whose descriptor matches the scan tuple slot
for the ForeignScan node. But in the case where the outer plan contains
an extra Sort node, if the new tlist contained columns required only for
evaluating PlaceHolderVars or columns required only for evaluating local
conditions, this would cause setrefs.c to fail with the error.
The cause of this is that when creating the outer plan by injecting the
Sort node into an alternative local join plan that could emit such extra
columns as well, we fail to arrange for the outer plan to propagate them
up through the Sort node, causing setrefs.c to fail to match up them in
the new tlist to what is available from the outer plan. Repair.
Per report from Alexander Pyhalov.
Richard Guo and Etsuro Fujita, reviewed by Alexander Pyhalov and Tom Lane.
Backpatch to all supported versions.
Discussion: http://postgr.es/m/cfb17bf6dfdf876467bd5ef533852d18%40postgrespro.ru
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
Fix incorrect value for "strategy" with deflateParams() in walmethods.c
commit : a94576c377b7934860d2fa5453d1cf17d8689810
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 14 Sep 2022 14:52:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 14 Sep 2022 14:52:30 +0900
The zlib documentation mentions the values supported for the compression
strategy, but this code has been using a hardcoded value of 0 rather
than Z_DEFAULT_STRATEGY. This commit adjusts the code to use
Z_DEFAULT_STRATEGY.
Backpatch down to where this code has been added to ease the backport of
any future patch touching this area.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/1400032.1662217889@sss.pgh.pa.us
Backpatch-through: 10
M src/bin/pg_basebackup/walmethods.c
Expand palloc/pg_malloc API for more type safety
commit : 1728822924511e792760737aab8749e294af2c1c
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 14 Sep 2022 06:04:24 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 14 Sep 2022 06:04:24 +0200
This adds additional variants of palloc, pg_malloc, etc. that
encapsulate common usage patterns and provide more type safety.
Specifically, this adds palloc_object(), palloc_array(), and
repalloc_array(), which take the type name of the object to be
allocated as its first argument and cast the return as a pointer to
that type. There are also palloc0_object() and palloc0_array()
variants for initializing with zero, and pg_malloc_*() variants of all
of the above.
Inspired by the talloc library.
This is backpatched from master so that future backpatchable code can
make use of these APIs. This patch by itself does not contain any
users of these APIs.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/bb755632-2a43-d523-36f8-a1e7a389a907@enterprisedb.com
M src/include/common/fe_memutils.h
M src/include/utils/palloc.h
doc: Fix link to FreeBSD documentation project
commit : 9394fe05e7fe851461af287dfd28b8bc45c072c7
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Mon, 12 Sep 2022 22:17:17 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Mon, 12 Sep 2022 22:17:17 +0200
The FreeBSD site was changed with a redirect, which in turn seems to
lead to a 404. Replace with the working link.
Author: James Coleman <jtc331@gmail.com>
Discussion: https://postgr.es/m/CAAaqYe_JZRj+KPn=hACtwsg1iLRYs=jYvxG1NW4AnDeUL1GD-Q@mail.gmail.com
M doc/src/sgml/docguide.sgml
Fix NaN comparison in circle_same test
commit : eb8b848079c3e3f8cd486f209e50d0114476d2e8
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Mon, 12 Sep 2022 12:59:06 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Mon, 12 Sep 2022 12:59:06 +0200
Commit c4c340088 changed geometric operators to use float4 and float8
functions, and handle NaN's in a better way. The circle sameness test
had a typo in the code which resulted in all comparisons with the left
circle having a NaN radius considered same.
postgres=# select '<(0,0),NaN>'::circle ~= '<(0,0),1>'::circle;
?column?
----------
t
(1 row)
This fixes the sameness test to consider the radius of both the left
and right circle.
Backpatch to v12 where this was introduced.
Author: Ranier Vilela <ranier.vf@gmail.com>
Discussion: https://postgr.es/m/CAEudQAo8dK=yctg2ZzjJuzV4zgOPBxRU5+Kb+yatFiddtQk6Rw@mail.gmail.com
Backpatch-through: v12
M src/backend/utils/adt/geo_ops.c
M src/test/regress/expected/geometry.out
Fix possible omission of variable storage markers in ECPG.
commit : a6618842fac3baaf486dda5b563c61bbdb7a06ae
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Sep 2022 15:34:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Sep 2022 15:34:04 -0400
The ECPG preprocessor converted code such as
static varchar str1[10], str2[20], str3[30];
into
static struct varchar_1 { int len; char arr[ 10 ]; } str1 ;
struct varchar_2 { int len; char arr[ 20 ]; } str2 ;
struct varchar_3 { int len; char arr[ 30 ]; } str3 ;
thus losing the storage attribute for the later variables.
Repeat the declaration for each such variable.
(Note that this occurred only for variables declared "varchar"
or "bytea", which may help explain how it escaped detection
for so long.)
Andrey Sokolov
Discussion: https://postgr.es/m/942241662288242@mail.yandex.ru
M src/interfaces/ecpg/preproc/ecpg.trailer
M src/interfaces/ecpg/preproc/type.h
M src/interfaces/ecpg/test/expected/preproc-variable.c
M src/interfaces/ecpg/test/expected/preproc-variable.stderr
M src/interfaces/ecpg/test/expected/preproc-variable.stdout
M src/interfaces/ecpg/test/preproc/variable.pgc
Reject bogus output from uuid_create(3).
commit : a61095aa7946ffe6959279a32813681b53afb60e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Sep 2022 12:41:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Sep 2022 12:41:36 -0400
When using the BSD UUID functions, contrib/uuid-ossp expects
uuid_create() to produce a version-1 UUID. FreeBSD still does so,
but in recent NetBSD releases that function produces a version-4
(random) UUID instead. That's not acceptable for our purposes:
if the user wanted v4 she would have asked for v4, not v1.
Hence, check the version digit and complain if it's not '1'.
Also drop the documentation's claim that the NetBSD implementation
is usable. It might be, depending on which OS version you're using,
but we're not going to get into that kind of detail.
(Maybe someday we should ditch all these external libraries
and just write our own UUID code, but today is not that day.)
Nazir Bilal Yavuz, with cosmetic adjustments and docs by me.
Backpatch to all supported versions.
Discussion: https://postgr.es/m/3848059.1661038772@sss.pgh.pa.us
Discussion: https://postgr.es/m/17358-89806e7420797025@postgresql.org
M contrib/uuid-ossp/uuid-ossp.c
M doc/src/sgml/installation.sgml
M doc/src/sgml/uuid-ossp.sgml
Choose FK name correctly during partition attachment
commit : 80ef25b1adb150b727dc411d5ec30261a19f6dca
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 8 Sep 2022 13:17:02 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 8 Sep 2022 13:17:02 +0200
During ALTER TABLE ATTACH PARTITION, if the name of a parent's foreign
key constraint is already used on the partition, the code tries to
choose another one before the FK attributes list has been populated,
so the resulting constraint name was "<relname>__fkey" instead of
"<relname>_<attrs>_fkey". Repair, and add a test case.
Backpatch to 12. In 11, the code to attach a partition was not smart
enough to cope with conflicting constraint names, so the problem doesn't
exist there.
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
Discussion: https://postgr.es/m/20220901184156.738ebee5@karst
M src/backend/commands/tablecmds.c
M src/test/regress/input/constraints.source
M src/test/regress/output/constraints.source
Further fixes for MULTIEXPR_SUBLINK fix.
commit : ccbb54c72990d412552fbc50098b2e998b888359
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Sep 2022 16:38:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Sep 2022 16:38:18 -0400
Some more things I didn't think about in commits 3f7323cbb et al:
MULTIEXPR_SUBLINK subplans might have been converted to initplans
instead of regular subplans, in which case they won't show up in
the modified targetlist. Fortunately, this would only happen if
they have no input parameters, which means that the problem we
originally needed to fix can't happen with them. Therefore, there's
no need to clone their output parameters, and thus it doesn't hurt
that we'll fail to see them in the first pass over the targetlist.
Nonetheless, this complicates matters greatly, because now we have
to distinguish output Params of initplans (which shouldn't get
renumbered) from those of regular subplans (which should).
This also breaks the simplistic scheme I used of assuming that the
subplans found in the targetlist have consecutive subLinkIds.
We really can't avoid the need to know the subplans' subLinkIds in
this code. To fix that, add subLinkId as the last field of SubPlan.
We can get away with that change in back branches because SubPlan
nodes will never be stored in the catalogs, and there's no ABI
break for external code that might be looking at the existing
fields of SubPlan.
Secondly, rewriteTargetListIU might have rolled up multiple
FieldStores or SubscriptingRefs into one targetlist entry,
breaking the assumption that there's at most one Param to fix
per targetlist entry. (That assumption is OK I think in the
ruleutils.c code I stole the logic from in 18f51083c, because
that only deals with pre-rewrite query trees. But it's
definitely not OK here.) Abandon that shortcut and just do a
full tree walk on the targetlist to ensure we find all the
Params we have to change.
Per bug #17606 from Andre Lin. As before, only v10-v13 need the
patch.
Discussion: https://postgr.es/m/17606-e5c8ad18d31db96a@postgresql.org
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/optimizer/plan/subselect.c
M src/include/nodes/primnodes.h
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Backpatch nbtree page deletion hardening.
commit : 43e409cea4687ec1abdcfe82cd0b80a87a8d6adc
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 5 Sep 2022 11:20:05 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 5 Sep 2022 11:20:05 -0700
Postgres 14 commit 5b861baa taught nbtree VACUUM to tolerate buggy
opclasses. VACUUM's inability to locate a to-be-deleted page's downlink
in the parent page was logged instead of throwing an error. VACUUM
could just press on with vacuuming the index, and vacuuming the table as
a whole.
There are now anecdotal reports of this error causing problems that were
much more disruptive than the underlying index corruption ever could be.
Anything that makes VACUUM unable to make forward progress against one
table/index ultimately risks making the system enter xidStopLimit mode.
There is no good reason to take any chances here, so backpatch the
hardening commit.
Author: Peter Geoghegan <pg@bowt.ie>
Discussion: https://postgr.es/m/CAH2-Wzm9HR6Pow=t-iQa57zT8qmX6_M4h14F-pTtb=xFDW5FBA@mail.gmail.com
Backpatch: 10-13 (all supported versions that lacked the hardening)
M src/backend/access/nbtree/nbtpage.c
Doc: clarify partitioned table limitations
commit : b70db6c83073b562a92aaba917aa787c46ea1b39
author : David Rowley <drowley@postgresql.org>
date : Mon, 5 Sep 2022 18:44:44 +1200
committer: David Rowley <drowley@postgresql.org>
date : Mon, 5 Sep 2022 18:44:44 +1200
Improve documentation regarding the limitations of unique and primary key
constraints on partitioned tables. The existing documentation didn't make
it clear that the constraint columns had to be present in the partition
key as bare columns. The reader could be led to believe that it was ok to
include the constraint columns as part of a function call's parameters or
as part of an expression. Additionally, the documentation didn't mention
anything about the fact that we disallow unique and primary key
constraints if the partition keys contain *any* function calls or
expressions, regardless of if the constraint columns appear as columns
elsewhere in the partition key.
The confusion here was highlighted by a report on the general mailing list
by James Vanns.
Discussion: https://postgr.es/m/CAH7vdhNF0EdYZz3GLpgE3RSJLwWLhEk7A_fiKS9dPBT3Dz_3eA@mail.gmail.com
Discussion: https://postgr.es/m/CAApHDvoU-u9iTqKjteYRFfi+UNEk7dbSAcyxEQD==vZt9B1KnA@mail.gmail.com
Reviewed-by: Erik Rijkers
Backpatch-through: 11
M doc/src/sgml/ddl.sgml
doc: Fix two queries related to jsonb functions
commit : 0cc46c825135ff0feb17462398058fba00d88739
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 3 Sep 2022 20:57:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 3 Sep 2022 20:57:33 +0900
These have been updated by the revert done in 2f2b18b, but the
pre-revert state was correct. Note that the result was incorrectly
formatted in the first case.
Author: Erik Rijkers
Discussion: https://postgr.es/m/13777e96-24b6-396b-cb16-8ad01b6ac130@xs4all.nl
Backpatch-through: 13
M doc/src/sgml/func.sgml
doc: simplify docs about analyze and inheritance/partitions
commit : adc15f49e68719ed55a2efb3942fcb5c89ed6d5f
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 2 Sep 2022 23:32:19 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 2 Sep 2022 23:32:19 -0400
Discussion: https://postgr.es/m/YxAqYijOsLzgLQgy@momjian.us
Backpatch-through: 10
M doc/src/sgml/ref/analyze.sgml
doc: clarify recursion internal behavior
commit : 0f590f0064b3a6f1a7492dcc2370819cda0a12c9
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 2 Sep 2022 21:57:41 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 2 Sep 2022 21:57:41 -0400
Reported-by: Drew DeVault
Discussion: https://postgr.es/m/20211018091720.31299-1-sir@cmpwn.com
Backpatch-through: 10
M doc/src/sgml/queries.sgml
Fix oversight in recent MULTIEXPR_SUBLINK fix.
commit : 18f51083c990c710bf7d5292965d0b3c0ef23dfa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Sep 2022 14:54:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Sep 2022 14:54:40 -0400
Commits 3f7323cbb et al missed the possibility that the Params
they are looking for could be buried under implicit coercions,
as well as other stuff that processIndirection() could add to
the original targetlist entry. Copy the code in ruleutils.c
that deals with such cases. (I thought about refactoring so
that there's just one copy; but seeing that we only need this
in old back branches, it seems not worth the trouble.)
Per off-list report from Andre Lin. As before, only v10-v13
need the patch.
Discussion: https://postgr.es/m/17596-c5357f61427a81dc@postgresql.org
M src/backend/optimizer/plan/subselect.c
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Doc: Update struct Trigger definition.
commit : d7bc6ea052ea96b1f9122947efe340b972252fe5
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 2 Sep 2022 16:45:04 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 2 Sep 2022 16:45:04 +0900
Commit 487e9861d added a new field to struct Trigger, but failed to
update the documentation to match; backpatch to v13 where that came in.
Reviewed by Richard Guo.
Discussion: https://postgr.es/m/CAPmGK17NY92CyxJ%2BBG7A3JZurmng4jfRfzPiBTtNupGMF0xW1g%40mail.gmail.com
M doc/src/sgml/trigger.sgml
Fix some possibly latent bugs in slab.c
commit : 210bece161b0e56e92aa4220180fb568c3f574ff
author : David Rowley <drowley@postgresql.org>
date : Thu, 1 Sep 2022 19:23:08 +1200
committer: David Rowley <drowley@postgresql.org>
date : Thu, 1 Sep 2022 19:23:08 +1200
Primarily, this fixes an incorrect calculation in SlabCheck which was
looking in the wrong byte for the sentinel check. The reason that we've
never noticed this before in the form of a failing sentinel check is
because the pre-check to this always fails because all current core users
of slab contexts have a chunk size which is already MAXALIGNed, therefore
there's never any space for the sentinel byte. It is possible that an
extension needs to use a slab context and if they do with a chunk size
that's not MAXALIGNed, then they'll likely get errors about overwritten
sentinel bytes.
Additionally, this patch changes various calculations which are being done
based on the sizeof(SlabBlock). Currently, sizeof(SlabBlock) is a
multiple of 8, therefore sizeof(SlabBlock) is the same as
MAXALIGN(sizeof(SlabBlock)), however, if we were to ever have to add any
fields to that struct as part of a bug fix, then SlabAlloc could end up
returning a non-MAXALIGNed pointer. To be safe, let's ensure we always
MAXALIGN sizeof(SlabBlock) before using it in any calculations.
This patch has already been applied to master in d5ee4db0e.
Diagnosed-by: Tomas Vondra, Tom Lane
Author: Tomas Vondra, David Rowley
Discussion: https://postgr.es/m/CAA4eK1%2B1JyW5TiL%3DyV-3Uq1CrfnTyn0Xrk5uArt31Z%3D8rgPhXQ%40mail.gmail.com
Backpatch-through: 10
M src/backend/utils/mmgr/slab.c
doc: in create statistics docs, mention analyze for parent info
commit : 5be9cffa9d83cee569d77286a5136ad27855f05a
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 23:11:46 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 23:11:46 -0400
Discussion: https://postgr.es/m/Yv1Bw8J+1pYfHiRl@momjian.us
Backpatch-through: 10
M doc/src/sgml/ref/create_statistics.sgml
doc: mention "bloom" as a possible index access method
commit : dfc94d3cc8f737f71082b136aa158310cbbdcce9
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 22:35:09 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 22:35:09 -0400
Also remove USING erroneously added recently.
Reported-by: Jeff Janes
Discussion: https://postgr.es/m/CAMkU=1zhCpC7hottyMWM5Pimr9vRLprSwzLg+7PgajWhKZqRzw@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/indices.sgml
M doc/src/sgml/ref/create_index.sgml
doc: use FILTER in aggregate example
commit : d55fdfb554348ffd8e3afc61d62523a8f7d4a78e
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 22:19:06 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 22:19:06 -0400
Reported-by: michal.palenik@freemap.sk
Discussion: https://postgr.es/m/163499710897.684.7420075366995883688@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/query.sgml
doc: clarify that pgcrypto's gen_random_uuid calls core func.
commit : 4e3eb6dd1a9ba5555de6d1ab0e30e4bb5d690f43
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 22:04:36 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 22:04:36 -0400
Previously it was just marked as a duplicate of the core function.
Reported-by: Andreas Dijkman
Discussion: https://postgr.es/m/17349-24d61e214429e8c1@postgresql.org
Backpatch-through: 13
M doc/src/sgml/pgcrypto.sgml
doc: split out the NATURAL/CROSS JOIN in SELECT syntax
commit : 181cc0906b9130f0acb37131a50c06a601ec115c
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 21:46:14 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 21:46:14 -0400
This allows the syntax to be more accurate about what clauses are
supported. Also switch an example query to use the ANSI join syntax.
Reported-by: Joel Jacobson
Discussion: https://postgr.es/m/67b71d3e-0c22-44df-a223-351f14418319@www.fastmail.com
Backpatch-through: 11
M doc/src/sgml/ref/select.sgml
doc: warn of SECURITY DEFINER schemas for non-sql_body functions
commit : b6fe152fc27a07322386b269651675083abb6545
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 21:10:37 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 21:10:37 -0400
Non-sql_body functions are evaluated at runtime.
Reported-by: Erki Eessaar
Discussion: https://postgr.es/m/AM9PR01MB8268BF5E74E119828251FD34FE409@AM9PR01MB8268.eurprd01.prod.exchangelabs.com
Backpatch-through: 10
M doc/src/sgml/ref/create_function.sgml
doc: mention that SET TIME ZONE often needs to be quoted
commit : c7dbe904f2f4ec409d903103477b9f857b314fa3
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 20:27:27 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 20:27:27 -0400
Also mention that time zone abbreviations are not supported.
Reported-by: philippe.godfrin@nov.com
Discussion: https://postgr.es/m/163888728952.1269.5167822676466793158@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/ref/set.sgml
doc: document the maximum char/varchar length value
commit : 716e3d18dd28ea75464c1ccc63f9a8aa41983203
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 19:43:06 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 19:43:06 -0400
Reported-by: Japin Li
Discussion: https://postgr.es/m/MEYP282MB1669B13E98AE531617CB1386B6979@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
Backpatch-through: 10
M doc/src/sgml/datatype.sgml
doc: show direction is optional in FETCH/MOVE's FROM/IN syntax
commit : ccbae5fd8d3b23182ce208df4b3fd018db385e69
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 19:28:41 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 19:28:41 -0400
It used to show direction was required for FROM/IN.
Reported-by: Rob <rirans@comcast.net>
Discussion: https://postgr.es/m/20211015165248.isqjceyilelhnu3k@localhost
Author: Rob <rirans@comcast.net>
Backpatch-through: 10
M doc/src/sgml/ref/fetch.sgml
M doc/src/sgml/ref/move.sgml
doc: simplify WITH clause syntax in CREATE DATABASE
commit : 6a6edc0c8b5f09ce77d0c3940252fd0450c2cb35
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 17:08:44 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 17:08:44 -0400
Reported-by: Rob <rirans@comcast.net>
Discussion: https://postgr.es/m/20211016171149.yaouvlw5kvux6dvk@localhost
Author: Rob <rirans@comcast.net>
Backpatch-through: 10
M doc/src/sgml/ref/create_database.sgml
Prevent long-term memory leakage in autovacuum launcher.
commit : 45f7152b9b382424431bdd65e57f9b8c75676aa2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Aug 2022 16:23:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Aug 2022 16:23:20 -0400
get_database_list() failed to restore the caller's memory context,
instead leaving current context set to TopMemoryContext which is
how CommitTransactionCommand() leaves it. The callers both think
they are using short-lived contexts, for the express purpose of
not having to worry about cleaning up individual allocations.
The net effect therefore is that supposedly short-lived allocations
could accumulate indefinitely in the launcher's TopMemoryContext.
Although this has been broken for a long time, it seems we didn't
have any obvious memory leak here until v15's rearrangement of the
stats logic. I (tgl) am not entirely convinced that there's no
other leak at all, though, and we're surely at risk of adding one
in future back-patched fixes. So back-patch to all supported
branches, even though this may be only a latent bug in pre-v15.
Reid Thompson
Discussion: https://postgr.es/m/972a4e12b68b0f96db514777a150ceef7dcd2e0f.camel@crunchydata.com
M src/backend/postmaster/autovacuum.c
In the Snowball dictionary, don't try to stem excessively-long words.
commit : f204ad3a2b19a33a72f0401b8640f68527539bd1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Aug 2022 10:42:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Aug 2022 10:42:05 -0400
If the input word exceeds 1000 bytes, don't pass it to the stemmer;
just return it as-is after case folding. Such an input is surely
not a word in any human language, so whatever the stemmer might
do to it would be pretty dubious in the first place. Adding this
restriction protects us against a known recursion-to-stack-overflow
problem in the Turkish stemmer, and it seems like good insurance
against any other safety or performance issues that may exist in
the Snowball stemmers. (I note, for example, that they contain no
CHECK_FOR_INTERRUPTS calls, so we really don't want them running
for a long time.) The threshold of 1000 bytes is arbitrary.
An alternative definition could have been to treat such words as
stopwords, but that seems like a bigger break from the old behavior.
Per report from Egor Chindyaskin and Alexander Lakhin.
Thanks to Olly Betts for the recommendation to fix it this way.
Discussion: https://postgr.es/m/1661334672.728714027@f473.i.mail.ru
M src/backend/snowball/dict_snowball.c
On NetBSD, force dynamic symbol resolution at postmaster start.
commit : a94b019d44e5e9cfa6e57dda52bcfaf2535e7acf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 30 Aug 2022 17:28:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 30 Aug 2022 17:28:32 -0400
The default of lazy symbol resolution means that when the postmaster
first reaches the select() call in ServerLoop, it'll need to resolve
the link to that libc entry point. NetBSD's dynamic loader takes
an internal lock while doing that, and if a signal interrupts the
operation then there is a risk of self-deadlock should the signal
handler do anything that requires that lock, as several of the
postmaster signal handlers do. The window for this is pretty narrow,
and timing considerations make it unlikely that a signal would arrive
right then anyway. But it's semi-repeatable on slow single-CPU
machines, and in principle the race could happen with any hardware.
The least messy solution to this is to force binding of dynamic
symbols at postmaster start, using the "-z now" linker option.
While we're at it, also use "-z relro" so as to provide a small
security gain.
It's not entirely clear whether any other platforms share this
issue, but for now we'll assume it's NetBSD-specific. (We might
later try to use "-z now" on more platforms for performance
reasons, but that would not likely be something to back-patch.)
Report and patch by me; the idea to fix it this way is from
Andres Freund.
Discussion: https://postgr.es/m/3384826.1661802235@sss.pgh.pa.us
M src/template/netbsd
Prevent WAL corruption after a standby promotion.
commit : 3f2701cda590d8250a745d40f70dbeb58a606be8
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 29 Aug 2022 10:47:12 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 29 Aug 2022 10:47:12 -0400
When a PostgreSQL instance performing archive recovery but not using
standby mode is promoted, and the last WAL segment that it attempted
to read ended in a partial record, the previous code would create
invalid WAL on the new timeline. The WAL from the previously timeline
would be copied to the new timeline up until the end of the last valid
record, but instead of beginning to write WAL at immediately
afterwards, the promoted server would write an overwrite contrecord at
the beginning of the next segment. The end of the previous segment
would be left as all-zeroes, resulting in failures if anything tried
to read WAL from that file.
The root of the issue is that ReadRecord() decides whether to set
abortedRecPtr and missingContrecPtr based on the value of StandbyMode,
but ReadRecord() switches to a new timeline based on the value of
ArchiveRecoveryRequested. We shouldn't try to write an overwrite
contrecord if we're switching to a new timeline, so change the test in
ReadRecod() to check ArchiveRecoveryRequested instead.
Code fix by Dilip Kumar. Comments by me incorporating suggested
language from Álvaro Herrera. Further review from Kyotaro Horiguchi
and Sami Imseih.
Discussion: http://postgr.es/m/CAFiTN-t7umki=PK8dT1tcPV=mOUe2vNhHML6b3T7W7qqvvajjg@mail.gmail.com
Discussion: http://postgr.es/m/FB0DEA0B-E14E-43A0-811F-C1AE93D00FF3%40amazon.com
M src/backend/access/transam/xlog.c
Doc: fix example of recursive query.
commit : 4079d91e1ce5439873c3a3a9bd790081ec1bd642
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Aug 2022 10:44:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Aug 2022 10:44:52 -0400
Compute total number of sub-parts correctly, per jason@banfelder.net
Simon Riggs
Discussion: https://postgr.es/m/166161184718.1235920.6304070286124217754@wrigleys.postgresql.org
M doc/src/sgml/queries.sgml
Repair rare failure of MULTIEXPR_SUBLINK subplans in inherited updates.
commit : 3f7323cbbdd3fddc54619b8bd0e0b03a27befdfc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 27 Aug 2022 12:11:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 27 Aug 2022 12:11:20 -0400
Prior to v14, if we have a MULTIEXPR SubPlan (that is, use of the syntax
UPDATE ... SET (c1, ...) = (SELECT ...)) in an UPDATE with an inherited
or partitioned target table, inheritance_planner() will clone the
targetlist and therefore also the MULTIEXPR SubPlan and the Param nodes
referencing it for each child target table. Up to now, we've allowed
all the clones to share the underlying subplan as well as the output
parameter IDs -- that is, the runtime ParamExecData slots. That
technique is borrowed from the far older code that supports initplans,
and it works okay in that case because the cloned SubPlan nodes are
essentially identical. So it doesn't matter which one of the clones
the shared ParamExecData.execPlan field might point to.
However, this fails to hold for MULTIEXPR SubPlans, because they can
have nonempty "args" lists (values to be passed into the subplan), and
those lists could get mutated to different states in the various clones.
In the submitted reproducer, as well as the test case added here, one
clone contains Vars with varno OUTER_VAR where another has INNER_VAR,
because the child tables are respectively on the outer or inner side of
the join. Sharing the execPlan pointer can result in trying to evaluate
an args list that doesn't match the local execution state, with mayhem
ensuing. The result often is to trigger consistency checks in the
executor, but I believe this could end in a crash or incorrect updates.
To fix, assign new Param IDs to each of the cloned SubPlans, so that
they don't share ParamExecData slots at runtime. It still seems fine
for the clones to share the underlying subplan, and extra ParamExecData
slots are cheap enough that this fix shouldn't cost much.
This has been busted since we invented MULTIEXPR SubPlans in 9.5.
Probably the lack of previous reports is because query plans in which
the different clones of a MULTIEXPR mutate to effectively-different
states are pretty rare. There's no issue in v14 and later, because
without inheritance_planner() there's never a reason to clone
MULTIEXPR SubPlans.
Per bug #17596 from Andre Lin. Patch v10-v13 only.
Discussion: https://postgr.es/m/17596-c5357f61427a81dc@postgresql.org
M src/backend/executor/nodeSubplan.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/subselect.c
M src/include/optimizer/subselect.h
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Fix typo in comment.
commit : 7d501657550619a6a826ab3cf282c3e7bf862bd0
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 26 Aug 2022 16:55:04 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 26 Aug 2022 16:55:04 +0900
M src/backend/commands/copy.c
Defend against stack overrun in a few more places.
commit : 2d1f1523ce830bd59c10cf144993fdd0bba50478
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Aug 2022 13:01:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Aug 2022 13:01:40 -0400
SplitToVariants() in the ispell code, lseg_inside_poly() in geo_ops.c,
and regex_selectivity_sub() in selectivity estimation could recurse
until stack overflow; fix by adding check_stack_depth() calls.
So could next() in the regex compiler, but that case is better fixed by
converting its tail recursion to a loop. (We probably get better code
that way too, since next() can now be inlined into its sole caller.)
There remains a reachable stack overrun in the Turkish stemmer, but
we'll need some advice from the Snowball people about how to fix that.
Per report from Egor Chindyaskin and Alexander Lakhin. These mistakes
are old, so back-patch to all supported branches.
Richard Guo and Tom Lane
Discussion: https://postgr.es/m/1661334672.728714027@f473.i.mail.ru
M src/backend/regex/regc_lex.c
M src/backend/tsearch/spell.c
M src/backend/utils/adt/geo_ops.c
M src/backend/utils/adt/like_support.c
Doc: document possible need to raise kernel's somaxconn limit.
commit : 3ccdeff7bf1971d4a4ecece02f3ba3ec64d4a3ad
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Aug 2022 09:55:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Aug 2022 09:55:37 -0400
On fast machines, it's possible for applications such as pgbench
to issue connection requests so quickly that the postmaster's
listen queue overflows in the kernel, resulting in unexpected
failures (with not-very-helpful error messages). Most modern OSes
allow the queue size to be increased, so document how to do that.
Per report from Kevin McKibbin.
Discussion: https://postgr.es/m/CADc_NKg2d+oZY9mg4DdQdoUcGzN2kOYXBu-3--RW_hEe0tUV=g@mail.gmail.com
M doc/src/sgml/runtime.sgml
Doc: prefer sysctl to /proc/sys in docs and comments.
commit : 384497f34de5435921ed2c32d29874f4f7532c3a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Aug 2022 09:41:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Aug 2022 09:41:37 -0400
sysctl is more portable than Linux's /proc/sys file tree, and
often easier to use too. That's why most of our docs refer to
sysctl when talking about how to adjust kernel parameters.
Bring the few stragglers into line.
Discussion: https://postgr.es/m/361175.1661187463@sss.pgh.pa.us
M doc/src/sgml/runtime.sgml
M src/backend/postmaster/postmaster.c
Add CHECK_FOR_INTERRUPTS while decoding changes.
commit : 4985a45917c88ae286ed76971154668e7d545832
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 23 Aug 2022 09:10:28 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 23 Aug 2022 09:10:28 +0530
While decoding changes in a loop, if we skip all the changes there is no
CFI making the loop uninterruptible.
Reported-by: Whale Song and Andrey Borodin
Bug: 17580
Author: Masahiko Sawada
Reviwed-by: Amit Kapila
Backpatch-through: 10
Discussion: https://postgr.es/m/17580-849c1d5b6d7eb422@postgresql.org
Discussion: https://postgr.es/m/B319ECD6-9A28-4CDF-A8F4-3591E0BF2369@yandex-team.ru
M src/backend/replication/logical/reorderbuffer.c
Fix subtly-incorrect matching of parent and child partitioned indexes.
commit : 9f0073ef7dac2837c45e7960d1157d4a69046b3c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Aug 2022 12:11:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Aug 2022 12:11:47 -0400
When creating a partitioned index, DefineIndex tries to identify
any existing indexes on the partitions that match the partitioned
index, so that it can absorb those as child indexes instead of
building new ones. Part of the matching is to compare IndexInfo
structs --- but that wasn't done quite right. We're comparing
the IndexInfo built within DefineIndex itself to one made from
existing catalog contents by BuildIndexInfo. Notably, while
BuildIndexInfo will run index expressions and predicates through
expression preprocessing, that has not happened to DefineIndex's
struct. The result is failure to match and subsequent creation
of duplicate indexes.
The easiest and most bulletproof fix is to build a new IndexInfo
using BuildIndexInfo, thereby guaranteeing that the processing done
is identical.
While here, let's also extract the opfamily and collation data
from the new partitioned index, removing ad-hoc logic that
duplicated knowledge about how those are constructed.
Per report from Christophe Pettus. Back-patch to v11 where
we invented partitioned indexes.
Richard Guo and Tom Lane
Discussion: https://postgr.es/m/8864BFAA-81FD-4BF9-8E06-7DEB8D4164ED@thebuild.com
M src/backend/commands/indexcmds.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql
Fix replica identity check for a partitioned table.
commit : 1df86aac517dc9251b491e71957c33275a1cc35a
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 16 Aug 2022 14:30:27 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 16 Aug 2022 14:30:27 +0530
The current publisher code checks if UPDATE or DELETE can be executed with
the replica identity of the table even if it's a partitioned table. We can
skip checking the replica identity for partitioned tables because the
operations are actually performed on the leaf partitions (not the
partitioned table).
Reported-by: Brad Nicholson
Author: Hou Zhijie
Reviewed-by: Peter Smith, Amit Kapila
Backpatch-through: 13
Discussion: https://postgr.es/m/CAMMnM%3D8i5DohH%3DYKzV0_wYuYSYvuOJoL9F5nzXTc%2ByzsG1f6rg%40mail.gmail.com
M src/backend/executor/execReplication.c
M src/test/regress/expected/publication.out
M src/test/regress/sql/publication.sql
doc: fix wrong tag used in create sequence manual.
commit : dc9ed21a4f4fc1da39c70935fc3dcd298b851542
author : Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 16 Aug 2022 09:28:19 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 16 Aug 2022 09:28:19 +0900
In ref/create_sequence.sgml <literal> tag was used for nextval function name.
This should have been <function> tag.
Author: Noboru Saito
Discussion: https://postgr.es/m/CAAM3qnJTDFFfRf5JHJ4AYrNcqXgMmj0pbH0%2Bvm%3DYva%2BpJyGymA%40mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/ref/create_sequence.sgml
Add missing bad-PGconn guards in libpq entry points.
commit : e37e9a65517552e79614a1c81c8aff216d033e59
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 15 Aug 2022 15:40:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 15 Aug 2022 15:40:07 -0400
There's a convention that externally-visible libpq functions should
check for a NULL PGconn pointer, and fail gracefully instead of
crashing. PQflush() and PQisnonblocking() didn't get that memo
though. Also add a similar check to PQdefaultSSLKeyPassHook_OpenSSL;
while it's not clear that ordinary usage could reach that with a
null conn pointer, it's cheap enough to check, so let's be consistent.
Daniele Varrazzo and Tom Lane
Discussion: https://postgr.es/m/CA+mi_8Zm_mVVyW1iNFgyMd9Oh0Nv8-F+7Y3-BqwMgTMHuo_h2Q@mail.gmail.com
M src/interfaces/libpq/fe-exec.c
M src/interfaces/libpq/fe-secure-openssl.c
Fix outdated --help message for postgres -f
commit : bcf7eb99bbf15954a92df0a4405713d561402be2
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 15 Aug 2022 13:37:40 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 15 Aug 2022 13:37:40 +0900
This option switch supports a total of 8 values, as told by
set_plan_disabling_options() and the documentation, but this was not
reflected in the output generated by --help.
Author: Junwang Zhao
Discussion: https://postgr.es/m/CAEG8a3+pT3cWzyjzKs184L1XMNm8NDnoJLiSjAYSO7XqpRh_vA@mail.gmail.com
Backpatch-through: 10
M src/backend/main/main.c
Preserve memory context of VarStringSortSupport buffers.
commit : 9fe285f8597d4a3ab3fce9223891b2af01a3393b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 14 Aug 2022 12:05:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 14 Aug 2022 12:05:27 -0400
When enlarging the work buffers of a VarStringSortSupport object,
varstrfastcmp_locale was careful to keep them in the ssup_cxt
memory context; but varstr_abbrev_convert just used palloc().
The latter creates a hazard that the buffers could be freed out
from under the VarStringSortSupport object, resulting in stomping
on whatever gets allocated in that memory later.
In practice, because we only use this code for ICU collations
(cf. 3df9c374e), the problem is confined to use of ICU collations.
I believe it may have been unreachable before the introduction
of incremental sort, too, as traditional sorting usually just
uses one context for the duration of the sort.
We could fix this by making the broken stanzas in varstr_abbrev_convert
match the non-broken ones in varstrfastcmp_locale. However, it seems
like a better idea to dodge the issue altogether by replacing the
pfree-and-allocate-anew coding with repalloc, which automatically
preserves the chunk's memory context. This fix does add a few cycles
because repalloc will copy the chunk's content, which the existing
coding assumes is useless. However, we don't expect that these buffer
enlargement operations are performance-critical. Besides that, it's
far from obvious that copying the buffer contents isn't required, since
these stanzas make no effort to mark the buffers invalid by resetting
last_returned, cache_blob, etc. That seems to be safe upon examination,
but it's fragile and could easily get broken in future, which wouldn't
get revealed in testing with short-to-moderate-size strings.
Per bug #17584 from James Inform. Whether or not the issue is
reachable in the older branches, this code has been broken on its
own terms from its introduction, so patch all the way back.
Discussion: https://postgr.es/m/17584-95c79b4a7d771f44@postgresql.org
M src/backend/utils/adt/varlena.c
Avoid misbehavior when hash_table_bytes < bucket_size.
commit : 4878ea717c7166e3453cb94796a2044837bf1d2b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Aug 2022 16:59:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Aug 2022 16:59:58 -0400
It's possible to reach this case when work_mem is very small and tupsize
is (relatively) very large. In that case ExecChooseHashTableSize would
get an assertion failure, or with asserts off it'd compute nbuckets = 0,
which'd likely cause misbehavior later (I've not checked). To fix,
clamp the number of buckets to be at least 1.
This is due to faulty conversion of old my_log2() coding in 28d936031.
Back-patch to v13, as that was.
Zhang Mingli
Discussion: https://postgr.es/m/beb64ca0-91e2-44ac-bf4a-7ea36275ec02@Spark
M src/backend/executor/nodeHash.c
Catch stack overflow when recursing in transformFromClauseItem().
commit : 60f876317efc7b9ad624b11ae2f4b8208e408ef4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Aug 2022 15:21:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Aug 2022 15:21:28 -0400
Most parts of the parser can expect that the stack overflow check
in transformExprRecurse() will trigger before things get desperate.
However, transformFromClauseItem() can recurse directly to self
without having analyzed any expressions, so it's possible to drive
it to a stack-overrun crash. Add a check to prevent that.
Per bug #17583 from Egor Chindyaskin. Back-patch to all supported
branches.
Richard Guo
Discussion: https://postgr.es/m/17583-33be55b9f981f75c@postgresql.org
M src/backend/parser/parse_clause.c
Add missing fields to _outConstraint()
commit : 8b2638fdd4ac87052afb5ebc0d3251bb1ace4bcb
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 13 Aug 2022 10:32:38 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 13 Aug 2022 10:32:38 +0200
As of 897795240cfaaed724af2f53ed2c50c9862f951f, check constraints can
be declared invalid. But that patch didn't update _outConstraint() to
also show the relevant struct fields (which were only applicable to
foreign keys before that). This currently only affects debugging
output, so no impact in practice.
M src/backend/nodes/outfuncs.c
pg_upgrade: Fix some minor code issues
commit : 8e40d16e954195c7bce7070a26174fcca3164882
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 13 Aug 2022 00:00:41 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 13 Aug 2022 00:00:41 +0200
96ef3b8ff1cf1950e897fd2f766d4bd9ef0d5d56 accidentally copied a not
applicable comment from the float8_pass_by_value code to the
data_checksums code. Remove that.
87d3b35a1ca31a9d947a8f919a6006679216dff0 changed pg_upgrade to
checking the checksum version rather than just the Boolean presence of
checksums, but didn't change the field type in its ControlData struct
from bool. So this would not work correctly if there ever is a
checksum version larger than 1.
M src/bin/pg_upgrade/controldata.c
M src/bin/pg_upgrade/pg_upgrade.h
doc: add missing role attributes to user management section
commit : 1a2ad6e3bd042cf64c2321de36abf7db2bb50578
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 15:43:23 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 15:43:23 -0400
Reported-by: Shinya Kato
Discussion: https://postgr.es/m/1ecdb1ff78e9b03dfce37e85eaca725a@oss.nttdata.com
Author: Shinya Kato
Backpatch-through: 10
M doc/src/sgml/user-manag.sgml
doc: add section about heap-only tuples (HOT)
commit : a9885f2c77e0ecbc9487a1c729b39ebbf3d03d29
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 15:05:12 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 15:05:12 -0400
Reported-by: Jonathan S. Katz
Discussion: https://postgr.es/m/c59ffbd5-96ac-a5a5-a401-14f627ca1405@postgresql.org
Backpatch-through: 11
M doc/src/sgml/acronyms.sgml
M doc/src/sgml/btree.sgml
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/indexam.sgml
M doc/src/sgml/indices.sgml
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/ref/create_table.sgml
M doc/src/sgml/storage.sgml
doc: warn about security issues around log files
commit : a4a24feff4652a5ba4ce6fc3638da139de32d752
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 12:02:20 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 12:02:20 -0400
Reported-by: Simon Riggs
Discussion: https://postgr.es/m/CANP8+jJESuuXYq9Djvf-+tx2vY2OFLmfEuu+UvwHNJ1RT7iJCQ@mail.gmail.com
Author: Simon Riggs
Backpatch-through: 10
M doc/src/sgml/config.sgml
M doc/src/sgml/maintenance.sgml
doc: clarify configuration file for Windows builds
commit : d1303bc9777837e3492a944fd926e770c70e0a91
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 11:35:23 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 11:35:23 -0400
The use of file 'config.pl' was not clearly explained.
Reported-by: liambowen@gmail.com
Discussion: https://postgr.es/m/164246013804.31952.4958087335645367498@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/install-windows.sgml
doc: document the CREATE INDEX "USING" clause
commit : 1b30571a22d5b06ae86c5f0341dd6ca57ce4126b
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 11:26:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 11:26:03 -0400
Somehow this was in the syntax but had no description.
Reported-by: robertcorrington@gmail.com
Discussion: https://postgr.es/m/164228771825.31954.2719791849363756957@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/ref/create_index.sgml
doc: clarify CREATE TABLE AS ... IF NOT EXISTS
commit : e1785d8d9f171d988ff30bace10ef563b532bb4f
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 10:59:00 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 10:59:00 -0400
Mention that the table is not modified if it already exists.
Reported-by: frank_limpert@yahoo.com
Discussion: https://postgr.es/m/164441177106.9677.5991676148704507229@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/ref/create_table_as.sgml
doc: improve wal_level docs for the 'minimal' level
commit : 483c426abd61a997af1b8865e65532c4a9e27bbe
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 10:30:00 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 10:30:00 -0400
Reported-by: David G. Johnston
Discussion: https://postgr.es/m/CAKFQuwZ24UcfkoyLLSW3PMGQATomOcw1nuYFRuMev-NoOF+mYw@mail.gmail.com
Author: David G. Johnston
Backpatch-through: 14, partial to 13
M doc/src/sgml/config.sgml
doc: clarify DROP EXTENSION dependent members text
commit : ec55acbda581e999c1314caa078c91e553433f9a
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 09:06:47 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 09:06:47 -0400
Member tracking was added in PG 13.
Reported-by: David G. Johnston
Discussion: https://postgr.es/m/CAKFQuwY1YtxQHVWUFYvSnOjZ5VPpXjF33V52bSKEwFjK2K=1Aw@mail.gmail.com
Author: David G. Johnston
Backpatch-through: 13
M doc/src/sgml/ref/drop_extension.sgml
Fix _outConstraint() for "identity" constraints
commit : f70dfbf36f1ab72b0a6eb19e766967883c894676
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 12 Aug 2022 08:17:30 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 12 Aug 2022 08:17:30 +0200
The set of fields printed by _outConstraint() in the CONSTR_IDENTITY
case didn't match the set of fields actually used in that case. (The
code was probably uncarefully copied from the CONSTR_DEFAULT case.)
Fix that by using the right set of fields. Since there is no read
support for this node type, this is really just for debugging output
right now, so it doesn't affect anything important.
M src/backend/nodes/outfuncs.c
Back-Patch "Add wait_for_subscription_sync for TAP tests."
commit : 5afa63f0aed96a8978489bdba38ef9998bb3aef0
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 12 Aug 2022 11:04:46 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 12 Aug 2022 11:04:46 +0530
This was originally done in commit 0c20dd33db for 16 only, to eliminate
duplicate code and as an infrastructure that makes it easier to write
future tests. However, it has been suggested that it would be good to
back-patch this testing infrastructure to aid future tests in
back-branches.
Backpatch to all supported versions.
Author: Masahiko Sawada
Reviewed by: Amit Kapila, Shi yu
Discussion: https://postgr.es/m/CAD21AoC-fvAkaKHa4t1urupwL8xbAcWRePeETvshvy80f6WV1A@mail.gmail.com
Discussion: https://postgr.es/m/E1oJBIf-0006sw-SA@gemulon.postgresql.org
M src/test/perl/PostgresNode.pm
M src/test/subscription/t/001_rep_changes.pl
M src/test/subscription/t/002_types.pl
M src/test/subscription/t/004_sync.pl
M src/test/subscription/t/005_encoding.pl
M src/test/subscription/t/006_rewrite.pl
M src/test/subscription/t/008_diff_schema.pl
M src/test/subscription/t/010_truncate.pl
M src/test/subscription/t/011_generated.pl
M src/test/subscription/t/013_partition.pl
M src/test/subscription/t/100_bugs.pl
Fix catalog lookup with the wrong snapshot during logical decoding.
commit : 547b963683e34e9f26401093131f9bea89d48968
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 11 Aug 2022 09:30:55 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 11 Aug 2022 09:30:55 +0530
Previously, we relied on HEAP2_NEW_CID records and XACT_INVALIDATION
records to know if the transaction has modified the catalog, and that
information is not serialized to snapshot. Therefore, after the restart,
if the logical decoding decodes only the commit record of the transaction
that has actually modified a catalog, we will miss adding its XID to the
snapshot. Thus, we will end up looking at catalogs with the wrong
snapshot.
To fix this problem, this changes the snapshot builder so that it
remembers the last-running-xacts list of the decoded RUNNING_XACTS record
after restoring the previously serialized snapshot. Then, we mark the
transaction as containing catalog changes if it's in the list of initial
running transactions and its commit record has XACT_XINFO_HAS_INVALS. To
avoid ABI breakage, we store the array of the initial running transactions
in the static variables InitialRunningXacts and NInitialRunningXacts,
instead of storing those in SnapBuild or ReorderBuffer.
This approach has a false positive; we could end up adding the transaction
that didn't change catalog to the snapshot since we cannot distinguish
whether the transaction has catalog changes only by checking the COMMIT
record. It doesn't have the information on which (sub) transaction has
catalog changes, and XACT_XINFO_HAS_INVALS doesn't necessarily indicate
that the transaction has catalog change. But that won't be a problem since
we use snapshot built during decoding only to read system catalogs.
On the master branch, we took a more future-proof approach by writing
catalog modifying transactions to the serialized snapshot which avoids the
above false positive. But we cannot backpatch it because of a change in
the SnapBuild.
Reported-by: Mike Oh
Author: Masahiko Sawada
Reviewed-by: Amit Kapila, Shi yu, Takamichi Osumi, Kyotaro Horiguchi, Bertrand Drouvot, Ahsan Hadi
Backpatch-through: 10
Discussion: https://postgr.es/m/81D0D8B0-E7C4-4999-B616-1E5004DBDCD2%40amazon.com
M contrib/test_decoding/Makefile
A contrib/test_decoding/expected/catalog_change_snapshot.out
A contrib/test_decoding/specs/catalog_change_snapshot.spec
M src/backend/replication/logical/decode.c
M src/backend/replication/logical/snapbuild.c
M src/include/replication/snapbuild.h
Fix handling of R/W expanded datums that are passed to SQL functions.
commit : 71caf3c4da1c85a2ec7cfce914f1ccb723c8e991
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Aug 2022 13:37:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Aug 2022 13:37:25 -0400
fmgr_sql must make expanded-datum arguments read-only, because
it's possible that the function body will pass the argument to
more than one callee function. If one of those functions takes
the datum's R/W property as license to scribble on it, then later
callees will see an unexpected value, leading to wrong answers.
From a performance standpoint, it'd be nice to skip this in the
common case that the argument value is passed to only one callee.
However, detecting that seems fairly hard, and certainly not
something that I care to attempt in a back-patched bug fix.
Per report from Adam Mackler. This has been broken since we
invented expanded datums, so back-patch to all supported branches.
Discussion: https://postgr.es/m/WScDU5qfoZ7PB2gXwNqwGGgDPmWzz08VdydcPFLhOwUKZcdWbblbo-0Lku-qhuEiZoXJ82jpiQU4hOjOcrevYEDeoAvz6nR0IU4IHhXnaCA=@mackler.email
Discussion: https://postgr.es/m/187436.1660143060@sss.pgh.pa.us
M src/backend/executor/functions.c
M src/test/regress/expected/create_function_3.out
M src/test/regress/sql/create_function_3.sql
Stamp 13.8.
commit : 4bc493d14409857090928ea51c02a20aba8db364
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Aug 2022 16:45:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Aug 2022 16:45:58 -0400
M configure
M configure.in
Stabilize output of new regression test.
commit : 22b205cbbd978e69f08bd2b980adae29a6ca1979
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Aug 2022 12:16:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Aug 2022 12:16:01 -0400
Per buildfarm, the output order of \dx+ isn't consistent across
locales. Apply NO_LOCALE to force C locale. There might be a
more localized way, but I'm not seeing it offhand, and anyway
there is nothing in this test module that particularly cares
about locales.
Security: CVE-2022-2625
M src/test/modules/test_extensions/Makefile
Last-minute updates for release notes.
commit : 30523c0ca1186476674d2874754cf218627e9de2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Aug 2022 11:28:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Aug 2022 11:28:47 -0400
Security: CVE-2022-2625
M doc/src/sgml/release-13.sgml
In extensions, don't replace objects not belonging to the extension.
commit : 7e92f78abe80e4b30e648a40073abb59057e21f8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Aug 2022 11:12:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Aug 2022 11:12:31 -0400
Previously, if an extension script did CREATE OR REPLACE and there was
an existing object not belonging to the extension, it would overwrite
the object and adopt it into the extension. This is problematic, first
because the overwrite is probably unintentional, and second because we
didn't change the object's ownership. Thus a hostile user could create
an object in advance of an expected CREATE EXTENSION command, and would
then have ownership rights on an extension object, which could be
modified for trojan-horse-type attacks.
Hence, forbid CREATE OR REPLACE of an existing object unless it already
belongs to the extension. (Note that we've always forbidden replacing
an object that belongs to some other extension; only the behavior for
previously-free-standing objects changes here.)
For the same reason, also fail CREATE IF NOT EXISTS when there is
an existing object that doesn't belong to the extension.
Our thanks to Sven Klemm for reporting this problem.
Security: CVE-2022-2625
M doc/src/sgml/extend.sgml
M src/backend/catalog/pg_collation.c
M src/backend/catalog/pg_depend.c
M src/backend/catalog/pg_operator.c
M src/backend/catalog/pg_type.c
M src/backend/commands/createas.c
M src/backend/commands/foreigncmds.c
M src/backend/commands/schemacmds.c
M src/backend/commands/sequence.c
M src/backend/commands/statscmds.c
M src/backend/commands/view.c
M src/backend/parser/parse_utilcmd.c
M src/include/catalog/dependency.h
M src/test/modules/test_extensions/Makefile
M src/test/modules/test_extensions/expected/test_extensions.out
M src/test/modules/test_extensions/sql/test_extensions.sql
A src/test/modules/test_extensions/test_ext_cine–1.0–1.1.sql
A src/test/modules/test_extensions/test_ext_cine–1.0.sql
A src/test/modules/test_extensions/test_ext_cine.control
A src/test/modules/test_extensions/test_ext_cor–1.0.sql
A src/test/modules/test_extensions/test_ext_cor.control
Translation updates
commit : 330c48b28470ce423769b95e18a65e20d7d8a9b8
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 8 Aug 2022 12:39:52 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 8 Aug 2022 12:39:52 +0200
Source-Git-URL: ssh://git@git.postgresql.org/pgtranslation/messages.git
Source-Git-Hash: 8ee19d25e0753a690bea62ddcbbfaf2e0d093c1d
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/sv.po
M src/backend/po/uk.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/ja.po
M src/bin/initdb/po/uk.po
M src/bin/pg_archivecleanup/po/es.po
M src/bin/pg_archivecleanup/po/uk.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_basebackup/po/ja.po
M src/bin/pg_basebackup/po/uk.po
M src/bin/pg_checksums/po/es.po
M src/bin/pg_checksums/po/ja.po
M src/bin/pg_checksums/po/uk.po
M src/bin/pg_config/po/es.po
M src/bin/pg_config/po/uk.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/uk.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/uk.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/ja.po
M src/bin/pg_dump/po/uk.po
M src/bin/pg_resetwal/po/es.po
M src/bin/pg_resetwal/po/ja.po
M src/bin/pg_resetwal/po/uk.po
M src/bin/pg_rewind/po/es.po
M src/bin/pg_rewind/po/ja.po
M src/bin/pg_rewind/po/uk.po
M src/bin/pg_test_fsync/po/es.po
M src/bin/pg_test_fsync/po/ja.po
M src/bin/pg_test_fsync/po/uk.po
M src/bin/pg_test_timing/po/es.po
M src/bin/pg_test_timing/po/ja.po
M src/bin/pg_test_timing/po/uk.po
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/es.po
M src/bin/pg_upgrade/po/ja.po
M src/bin/pg_upgrade/po/uk.po
M src/bin/pg_verifybackup/po/es.po
M src/bin/pg_verifybackup/po/uk.po
M src/bin/pg_waldump/po/es.po
M src/bin/pg_waldump/po/uk.po
M src/bin/psql/po/es.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/sv.po
M src/bin/psql/po/uk.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/ja.po
M src/bin/scripts/po/uk.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/ja.po
M src/interfaces/ecpg/ecpglib/po/uk.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/ja.po
M src/interfaces/ecpg/preproc/po/uk.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/uk.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/ja.po
M src/pl/plperl/po/ro.po
M src/pl/plperl/po/uk.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/ja.po
M src/pl/plpgsql/src/po/uk.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/ja.po
M src/pl/plpython/po/uk.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/ja.po
M src/pl/tcl/po/uk.po
Release notes for 14.5, 13.8, 12.12, 11.17, 10.22.
commit : f339e5c1d4749e315422910888a4368141b3d990
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Aug 2022 15:46:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Aug 2022 15:46:27 -0400
M doc/src/sgml/release-13.sgml
Remove unportable use of timezone in recent test
commit : 1626590f2eb655ab13a6291f6ed6215376a1e90a
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 7 Aug 2022 10:19:40 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 7 Aug 2022 10:19:40 +0200
Per buildfarm member snapper
Discussion: https://postgr.es/m/129951.1659812518@sss.pgh.pa.us
M src/test/modules/brin/t/02_wal_consistency.pl
Improve recently-added test reliability
commit : 8c5d9ccca9670e8d7eda35e08b35e4e16bcf600c
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sat, 6 Aug 2022 15:52:10 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sat, 6 Aug 2022 15:52:10 +0200
Commit 59be1c942a47 already tried to make
src/test/recovery/t/033_replay_tsp_drops more reliable, but it wasn't
enough. Try to improve on that by making this use of a replication slot
to be more like others. Also, don't drop the slot.
Make a few other stylistic changes while at it. It's still quite slow,
which is another thing that we need to fix in this script.
Backpatch to all supported branches.
Discussion: https://postgr.es/m/349302.1659191875@sss.pgh.pa.us
M src/test/recovery/t/033_replay_tsp_drops.pl
Partially undo commit 94da73281.
commit : 476f9d533084f2ad3f625b5092021b6c23c8e196
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2022 15:57:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2022 15:57:46 -0400
On closer inspection, mcv.c isn't as broken for ScalarArrayOpExpr
as I thought. The Var-on-right issue is real enough, but actually
it does cope fine with a NULL array constant --- I was misled by
an XXX comment suggesting it didn't. Undo that part of the code
change, and replace the XXX comment with something less misleading.
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
Fix non-bulletproof ScalarArrayOpExpr code for extended statistics.
commit : c102d1106732189de2bfeb93c11b358f9c6b4e1f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2022 13:58:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2022 13:58:37 -0400
statext_is_compatible_clause_internal() checked that the arguments
of a ScalarArrayOpExpr are one Var and one Const, but it would allow
cases where the Const was on the left. Subsequent uses of the clause
are not expecting that and would suffer assertion failures or core
dumps. mcv.c also had not bothered to cope with the case of a NULL
array constant, which seems really unacceptably sloppy of somebody.
(Although our tools failed us there too, since AFAIK neither Coverity
nor any compiler warned of the obvious use-of-uninitialized-variable
condition.) It seems best to handle that by having
statext_is_compatible_clause_internal() reject it.
Noted while fixing bug #17570. Back-patch to v13 where the
extended stats code grew some awareness of ScalarArrayOpExpr.
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Backpatch addition of .git-blame-ignore-revs
commit : c122a99bd6af1d764fa74b5e1c811b4cd73987cd
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 5 Aug 2022 19:36:24 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 5 Aug 2022 19:36:24 +0200
This makes it more convenient for git config to contain the
blame.ignoreRevsFile setting; otherwise current git versions complain if
the file is not present.
I constructed the file for each branch by scraping the file in branch
master for commits that appear in that branch. Because a few additional
pgindent commits have been added to the list in master since the list
was first created, this also propagates those to branches 14 and 15
where the file already existed. Also, some entries appear to have been
made using author-date rather than committer-date in the format string,
so some timestamps are changed. Also remove bogus whitespace in the
suggested `git log` format string.
Backpatch to all supported branches.
Discussion: https://postgr.es/m/20220711163138.o72evdeus5f5yy5z@alvherre.pgsql
A .git-blame-ignore-revs
BRIN: mask BRIN_EVACUATE_PAGE for WAL consistency checking
commit : de31e6f81e84d53b1cb3d2f14705e4895a4b23d0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 5 Aug 2022 18:00:17 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 5 Aug 2022 18:00:17 +0200
That bit is unlogged and therefore it's wrong to consider it in WAL page
comparison.
Add a test that tickles the case, as branch testing technology allows.
This has been a problem ever since wal consistency checking was
introduced (commit a507b86900f6 for pg10), so backpatch to all supported
branches.
Author: 王海洋 (Haiyang Wang) <wanghaiyang.001@bytedance.com>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://postgr.es/m/CACciXAD2UvLMOhc4jX9VvOKt7DtYLr3OYRBhvOZ-jRxtzc_7Jg@mail.gmail.com
Discussion: https://postgr.es/m/CACciXADOfErX9Bx0nzE_SkdfXr6Bbpo5R=v_B6MUTEYW4ya+cg@mail.gmail.com
M src/backend/access/brin/brin_pageops.c
M src/backend/access/brin/brin_xlog.c
A src/test/modules/brin/t/02_wal_consistency.pl
Add HINT for restartpoint race with KeepFileRestoredFromArchive().
commit : ad8ebcfe9662c6145342f6f02ad7c46108f135b9
author : Noah Misch <noah@leadboat.com>
date : Fri, 5 Aug 2022 08:30:58 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 5 Aug 2022 08:30:58 -0700
The five commits ending at cc2c7d65fc27e877c9f407587b0b92d46cd6dd16
closed this race condition for v15+. For v14 through v10, add a HINT to
discourage studying the cosmetic problem.
Reviewed by Kyotaro Horiguchi and David Steele.
Discussion: https://postgr.es/m/20220731061747.GA3692882@rfd.leadboat.com
M src/backend/access/transam/xlog.c
M src/backend/storage/file/fd.c
regress: fix test instability
commit : d2a74621ed0430094e6d1f754df5bc1647408be7
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 5 Aug 2022 11:55:52 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 5 Aug 2022 11:55:52 +0200
Having additional triggers in a test table made the ORDER BY clauses in
old queries underspecified. Add another column there for stability.
Per sporadic buildfarm pink.
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Fix ENABLE/DISABLE TRIGGER to handle recursion correctly
commit : ab855663012c131bba8d16e6188eed0b627a27bc
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 4 Aug 2022 20:02:02 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 4 Aug 2022 20:02:02 +0200
Using ATSimpleRecursion() in ATPrepCmd() to do so as bbb927b4db9b did is
not correct, because ATPrepCmd() can't distinguish between triggers that
may be cloned and those that may not, so would wrongly try to recurse
for the latter category of triggers.
So this commit restores the code in EnableDisableTrigger() that
86f575948c77 had added to do the recursion, which would do it only for
triggers that may be cloned, that is, row-level triggers. This also
changes tablecmds.c such that ATExecCmd() is able to pass the value of
ONLY flag down to EnableDisableTrigger() using its new 'recurse'
parameter.
This also fixes what seems like an oversight of 86f575948c77 that the
recursion to partition triggers would only occur if EnableDisableTrigger()
had actually changed the trigger. It is more apt to recurse to inspect
partition triggers even if the parent's trigger didn't need to be
changed: only then can we be certain that all descendants share the same
state afterwards.
Backpatch all the way back to 11, like bbb927b4db9b. Care is taken not
to break ABI compatibility (and that no catversion bump is needed.)
Co-authored-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Dmitry Koval <d.koval@postgrespro.ru>
Discussion: https://postgr.es/m/CA+HiwqG-cZT3XzGAnEgZQLoQbyfJApVwOTQaCaas1mhpf+4V5A@mail.gmail.com
M src/backend/commands/tablecmds.c
M src/backend/commands/trigger.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/include/commands/trigger.h
M src/include/nodes/parsenodes.h
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Add CHECK_FOR_INTERRUPTS in ExecInsert's speculative insertion loop.
commit : 23edf0e8b4d1677f8e5269fb15a584155c2e08e2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 Aug 2022 14:10:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 Aug 2022 14:10:06 -0400
Ordinarily the functions called in this loop ought to have plenty
of CFIs themselves; but we've now seen a case where no such CFI is
reached, making the loop uninterruptible. Even though that's from
a recently-introduced bug, it seems prudent to install a CFI at
the loop level in all branches.
Per discussion of bug #17558 from Andrew Kesper (an actual fix for
that bug will follow).
Discussion: https://postgr.es/m/17558-3f6599ffcf52fd4a@postgresql.org
M src/backend/executor/nodeModifyTable.c
Add proper regression test for the recent SRFs-in-pathkeys problem.
commit : 8d38ccafca9382d79eee4badfa11b1114475622d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 Aug 2022 11:11:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 Aug 2022 11:11:22 -0400
Remove the test case added by commit fac1b470a, which never actually
worked to expose the problem it claimed to test. Replace it with
a case that does expose the problem, and also covers the SRF-not-
at-the-top deficiency repaired in 1aa8dad41.
Richard Guo, with some editorialization by me
Discussion: https://postgr.es/m/17564-c7472c2f90ef2da3@postgresql.org
M src/test/regress/expected/incremental_sort.out
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/incremental_sort.sql
M src/test/regress/sql/select_parallel.sql
Fix incorrect tests for SRFs in relation_can_be_sorted_early().
commit : da4ed7588132db44ab11bf52bad0472eb0c868e4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 Aug 2022 17:33:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 Aug 2022 17:33:42 -0400
Commit fac1b470a thought we could check for set-returning functions
by testing only the top-level node in an expression tree. This is
wrong in itself, and to make matters worse it encouraged others
to make the same mistake, by exporting tlist.c's special-purpose
IS_SRF_CALL() as a widely-visible macro. I can't find any evidence
that anyone's taken the bait, but it was only a matter of time.
Use expression_returns_set() instead, and stuff the IS_SRF_CALL()
genie back in its bottle, this time with a warning label. I also
added a couple of cross-reference comments.
After a fair amount of fooling around, I've despaired of making
a robust test case that exposes the bug reliably, so no test case
here. (Note that the test case added by fac1b470a is itself
broken, in that it doesn't notice if you remove the code change.
The repro given by the bug submitter currently doesn't fail either
in v15 or HEAD, though I suspect that may indicate an unrelated bug.)
Per bug #17564 from Martijn van Oosterhout. Back-patch to v13,
as the faulty patch was.
Discussion: https://postgr.es/m/17564-c7472c2f90ef2da3@postgresql.org
M src/backend/nodes/nodeFuncs.c
M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/util/tlist.c
M src/include/optimizer/optimizer.h
Reduce test runtime of src/test/modules/snapshot_too_old.
commit : b2694aebe33c8a664cb7fcaacc5a3fe30d120a09
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 Aug 2022 11:14:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 Aug 2022 11:14:55 -0400
The sto_using_cursor and sto_using_select tests were coded to exercise
every permutation of their test steps, but AFAICS there is no value in
exercising more than one. This matters because each permutation costs
about six seconds, thanks to the "pg_sleep(6)". Perhaps we could
reduce that, but the useless permutations seem worth getting rid of
in any case. (Note that sto_using_hash_index got it right already.)
While here, clean up some other sloppiness such as an unused table.
This doesn't make too much difference in interactive testing, since the
wasted time is typically masked by parallelization with other tests.
However, the buildfarm runs this as a serial step, which means we can
expect to shave ~40 seconds from every buildfarm run. That makes it
worth back-patching.
Discussion: https://postgr.es/m/2515192.1659454702@sss.pgh.pa.us
M src/test/modules/snapshot_too_old/expected/sto_using_cursor.out
M src/test/modules/snapshot_too_old/expected/sto_using_select.out
M src/test/modules/snapshot_too_old/specs/sto_using_cursor.spec
M src/test/modules/snapshot_too_old/specs/sto_using_select.spec
Be more wary about 32-bit integer overflow in pg_stat_statements.
commit : 6b67db10c366ee825345ef81dcca57d29ad4c7f1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Aug 2022 18:05:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Aug 2022 18:05:34 -0400
We've heard a couple of reports of people having trouble with
multi-gigabyte-sized query-texts files. It occurred to me that on
32-bit platforms, there could be an issue with integer overflow
of calculations associated with the total query text size.
Address that with several changes:
1. Limit pg_stat_statements.max to INT_MAX / 2 not INT_MAX.
The hashtable code will bound it to that anyway unless "long"
is 64 bits. We still need overflow guards on its use, but
this helps.
2. Add a check to prevent extending the query-texts file to
more than MaxAllocHugeSize. If it got that big, qtext_load_file
would certainly fail, so there's not much point in allowing it.
Without this, we'd need to consider whether extent, query_offset,
and related variables shouldn't be off_t not size_t.
3. Adjust the comparisons in need_gc_qtexts() to be done in 64-bit
arithmetic on all platforms. It appears possible that under duress
those multiplications could overflow 32 bits, yielding a false
conclusion that we need to garbage-collect the texts file, which
could lead to repeatedly garbage-collecting after every hash table
insertion.
Per report from Bruno da Silva. I'm not convinced that these
issues fully explain his problem; there may be some other bug that's
contributing to the query-texts file becoming so large in the first
place. But it did get that big, so #2 is a reasonable defense,
and #3 could explain the reported performance difficulties.
(See also commit 8bbe4cbd9, which addressed some related bugs.
The second Discussion: link is the thread that led up to that.)
This issue is old, and is primarily a problem for old platforms,
so back-patch.
Discussion: https://postgr.es/m/CAB+Nuk93fL1Q9eLOCotvLP07g7RAv4vbdrkm0cVQohDVMpAb9A@mail.gmail.com
Discussion: https://postgr.es/m/5601D354.5000703@BlueTreble.com
M contrib/pg_stat_statements/pg_stat_statements.c
Check maximum number of columns in function RTEs, too.
commit : 331f8b851c980d4050a82c1de101f93d47ddaacf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Aug 2022 12:22:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Aug 2022 12:22:35 -0400
I thought commit fd96d14d9 had plugged all the holes of this sort,
but no, function RTEs could produce oversize tuples too, either
via long coldeflists or just from multiple functions in one RTE.
(I'm pretty sure the other variants of base RTEs aren't a problem,
because they ultimately refer to either a table or a sub-SELECT,
whose widths are enforced elsewhere. But we explicitly allow join
RTEs to be overwidth, as long as you don't try to form their
tuple result.)
Per further discussion of bug #17561. As before, patch all branches.
Discussion: https://postgr.es/m/17561-80350151b9ad2ad4@postgresql.org
M src/backend/parser/parse_relation.c
Fix error reporting after ioctl() call with pg_upgrade --clone
commit : aadaaeff4cf8b90c62dbb6cc67f5dd7e5a0297fe
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 1 Aug 2022 16:39:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 1 Aug 2022 16:39:30 +0900
errno was not reported correctly after attempting to clone a file,
leading to incorrect error reports. While scanning through the code, I
have not noticed any similar mistakes.
Error introduced in 3a769d8.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20220731134135.GY15006@telsasoft.com
Backpatch-through: 12
M src/bin/pg_upgrade/file.c
Fix new recovery test for log_error_verbosity=verbose case
commit : b76e136ceb334a229ef99afdc9b4cb1cabfd05a7
author : Andrew Dunstan <andrew@dunslane.net>
date : Fri, 29 Jul 2022 17:43:34 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Fri, 29 Jul 2022 17:43:34 -0400
The new test is from commit 9e4f914b5e.
With this setting messages have SQL error numbers included, so that
needs to be provided for in the pattern looked for.
Backpatch to all live branches like the original.
M src/test/recovery/t/033_replay_tsp_drops.pl
In transformRowExpr(), check for too many columns in the row.
commit : ba2002d02cf4d6790d82d3b9ffd5d7a74a1c9589
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Jul 2022 13:30:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Jul 2022 13:30:50 -0400
A RowExpr with more than MaxTupleAttributeNumber columns would fail at
execution anyway, since we cannot form a tuple datum with more than that
many columns. While heap_form_tuple() has a check for too many columns,
it emerges that there are some intermediate bits of code that don't
check and can be driven to failure with sufficiently many columns.
Checking this at parse time seems like the most appropriate place to
install a defense, since we already check SELECT list length there.
While at it, make the SELECT-list-length error use the same errcode
(TOO_MANY_COLUMNS) as heap_form_tuple does, rather than the generic
PROGRAM_LIMIT_EXCEEDED.
Per bug #17561 from Egor Chindyaskin. The given test case crashes
in all supported branches (and probably a lot further back),
so patch all.
Discussion: https://postgr.es/m/17561-80350151b9ad2ad4@postgresql.org
M src/backend/parser/parse_expr.c
M src/backend/parser/parse_node.c
Fix test instability
commit : 7cfe688dee86c10ed2622872f5b2f8ca9b1b7c5b
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 29 Jul 2022 12:50:47 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 29 Jul 2022 12:50:47 +0200
On FreeBSD, the new test fails due to a WAL file being removed before
the standby has had the chance to copy it. Fix by adding a replication
slot to prevent the removal until after the standby has connected.
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reported-by: Matthias van de Meent <boekewurm+postgres@gmail.com>
Discussion: https://postgr.es/m/CAEze2Wj5nau_qpjbwihvmXLfkAWOZ5TKdbnqOc6nKSiRJEoPyQ@mail.gmail.com
M src/test/recovery/t/033_replay_tsp_drops.pl
Fix replay of create database records on standby
commit : 9a7e26b9c2ac7094f8a7d26cb32a8bc57d28d3f1
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 28 Jul 2022 08:26:05 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 28 Jul 2022 08:26:05 +0200
Crash recovery on standby may encounter missing directories
when replaying database-creation WAL records. Prior to this
patch, the standby would fail to recover in such a case;
however, the directories could be legitimately missing.
Consider the following sequence of commands:
CREATE DATABASE
DROP DATABASE
DROP TABLESPACE
If, after replaying the last WAL record and removing the
tablespace directory, the standby crashes and has to replay the
create database record again, crash recovery must be able to continue.
A fix for this problem was already attempted in 49d9cfc68bf4, but it
was reverted because of design issues. This new version is based
on Robert Haas' proposal: any missing tablespaces are created
during recovery before reaching consistency. Tablespaces
are created as real directories, and should be deleted
by later replay. CheckRecoveryConsistency ensures
they have disappeared.
The problems detected by this new code are reported as PANIC,
except when allow_in_place_tablespaces is set to ON, in which
case they are WARNING. Apart from making tests possible, this
gives users an escape hatch in case things don't go as planned.
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Author: Asim R Praveen <apraveen@pivotal.io>
Author: Paul Guo <paulguo@gmail.com>
Reviewed-by: Anastasia Lubennikova <lubennikovaav@gmail.com> (older versions)
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com> (older versions)
Reviewed-by: Michaël Paquier <michael@paquier.xyz>
Diagnosed-by: Paul Guo <paulguo@gmail.com>
Discussion: https://postgr.es/m/CAEET0ZGx9AvioViLf7nbR_8tH9-=27DN5xWJ2P9-ROH16e4JUA@mail.gmail.com
M src/backend/access/transam/xlog.c
M src/backend/commands/dbcommands.c
M src/backend/commands/tablespace.c
A src/test/recovery/t/033_replay_tsp_drops.pl
Allow "in place" tablespaces.
commit : 16e7a8fd8e97325c13c297f00eaa05a9ed739be5
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Jul 2022 07:55:13 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Jul 2022 07:55:13 +0200
This is a backpatch to branches 10-14 of the following commits:
7170f2159fb2 Allow "in place" tablespaces.
c6f2f01611d4 Fix pg_basebackup with in-place tablespaces.
f6f0db4d6240 Fix pg_tablespace_location() with in-place tablespaces
7a7cd84893e0 doc: Remove mention to in-place tablespaces for pg_tablespace_location()
5344723755bd Remove unnecessary Windows-specific basebackup code.
In-place tablespaces were introduced as a testing helper mechanism, but
they are going to be used for a bugfix in WAL replay to be backpatched
to all stable branches.
I (Álvaro) had to adjust some code to account for lack of
get_dirent_type() in branches prior to 14.
Author: Thomas Munro <thomas.munro@gmail.com>
Author: Michaël Paquier <michael@paquier.xyz>
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/20220722081858.omhn2in5zt3g4nek@alvherre.pgsql
M doc/src/sgml/config.sgml
M src/backend/access/transam/xlog.c
M src/backend/commands/tablespace.c
M src/backend/utils/adt/misc.c
M src/backend/utils/misc/guc.c
M src/include/commands/tablespace.h
Force immediate commit after CREATE DATABASE etc in extended protocol.
commit : 6c193c2ace32b4770cf13981914d9c054fb5404d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Jul 2022 13:07:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Jul 2022 13:07:03 -0400
We have a few commands that "can't run in a transaction block",
meaning that if they complete their processing but then we fail
to COMMIT, we'll be left with inconsistent on-disk state.
However, the existing defenses for this are only watertight for
simple query protocol. In extended protocol, we didn't commit
until receiving a Sync message. Since the client is allowed to
issue another command instead of Sync, we're in trouble if that
command fails or is an explicit ROLLBACK. In any case, sitting
in an inconsistent state while waiting for a client message
that might not come seems pretty risky.
This case wasn't reachable via libpq before we introduced pipeline
mode, but it's always been an intended aspect of extended query
protocol, and likely there are other clients that could reach it
before.
To fix, set a flag in PreventInTransactionBlock that tells
exec_execute_message to force an immediate commit. This seems
to be the approach that does least damage to existing working
cases while still preventing the undesirable outcomes.
While here, add some documentation to protocol.sgml that explicitly
says how to use pipelining. That's latent in the existing docs if
you know what to look for, but it's better to spell it out; and it
provides a place to document this new behavior.
Per bug #17434 from Yugo Nagata. It's been wrong for ages,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/17434-d9f7a064ce2a88a3@postgresql.org
M doc/src/sgml/protocol.sgml
M src/backend/access/transam/xact.c
M src/backend/tcop/postgres.c
M src/include/access/xact.h
Doc: improve documentation about random().
commit : 4c9e5162f56d2e9d8e690000a046ff4f59e2268d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Jul 2022 19:00:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Jul 2022 19:00:30 -0400
We didn't explicitly say that random() uses a randomly-chosen seed
if you haven't called setseed(). Do so.
Also, remove ref/set.sgml's no-longer-accurate (and never very
relevant) statement that the seed value is multiplied by 2^31-1.
Back-patch to v12 where set.sgml's claim stopped being true.
The claim that we use a source of random bits as seed was debatable
before 4203842a1, too, so v12 seems like a good place to stop.
Per question from Carl Sopchak.
Discussion: https://postgr.es/m/f37bb937-9d99-08f0-4de7-80c91a3cfc2e@sopchak.me
M doc/src/sgml/func.sgml
M doc/src/sgml/ref/set.sgml
doc: use wording "restore" instead of "reload" of dumps
commit : 43fe5134b0d40db6f120097dd045468f8100807b
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 21 Jul 2022 14:55:23 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 21 Jul 2022 14:55:23 -0400
Reported-by: axel.kluener@gmail.com
Discussion: https://postgr.es/m/164736074430.660.3645615289283943146@wrigleys.postgresql.org
Backpatch-through: 11
M doc/src/sgml/ddl.sgml
M doc/src/sgml/extend.sgml
M doc/src/sgml/perform.sgml
M doc/src/sgml/plhandler.sgml
M doc/src/sgml/ref/alter_type.sgml
M doc/src/sgml/ref/create_domain.sgml
M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_dumpall.sgml
M doc/src/sgml/ref/pg_resetwal.sgml
M doc/src/sgml/ref/pg_restore.sgml
M doc/src/sgml/ref/pgupgrade.sgml
M doc/src/sgml/runtime.sgml
M doc/src/sgml/textsearch.sgml
doc: clarify that auth. names are lower case and case-sensitive
commit : ea9581488bfa083a32b722dde16b67d4fa36f51a
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 21 Jul 2022 13:58:20 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 21 Jul 2022 13:58:20 -0400
This is true even for acronyms that are usually upper case, like LDAP.
Reported-by: Alvaro Herrera
Discussion: https://postgr.es/m/202205141521.2nodjabmsour@alvherre.pgsql
Backpatch-through: 10
M doc/src/sgml/client-auth.sgml
Fix ruleutils issues with dropped cols in functions-returning-composite.
commit : 5b5d4351398555d31b9419c764263981fa912755
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Jul 2022 13:56:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Jul 2022 13:56:02 -0400
Due to lack of concern for the case in the dependency code, it's
possible to drop a column of a composite type even though stored
queries have references to the dropped column via functions-in-FROM
that return the composite type. There are "soft" references,
namely FROM-clause aliases for such columns, and "hard" references,
that is actual Vars referring to them. The right fix for hard
references is to add dependencies preventing the drop; something
we've known for many years and not done (and this commit still doesn't
address it). A "soft" reference shouldn't prevent a drop though.
We've been around on this before (cf. 9b35ddce9, 2c4debbd0), but
nobody had noticed that the current behavior can result in dump/reload
failures, because ruleutils.c can print more column aliases than the
underlying composite type now has. So we need to rejigger the
column-alias-handling code to treat such columns as dropped and not
print aliases for them.
Rather than writing new code for this, I used expandRTE() which already
knows how to figure out which function result columns are dropped.
I'd initially thought maybe we could use expandRTE() in all cases, but
that fails for EXPLAIN's purposes, because the planner strips a lot of
RTE infrastructure that expandRTE() needs. So this patch just uses it
for unplanned function RTEs and otherwise does things the old way.
If there is a hard reference (Var), then removing the column alias
causes us to fail to print the Var, since there's no longer a name
to print. Failing seems less desirable than printing a made-up
name, so I made it print "?dropped?column?" instead.
Per report from Timo Stolz. Back-patch to all supported branches.
Discussion: https://postgr.es/m/5c91267e-3b6d-5795-189c-d15a55d61dbb@nullachtvierzehn.de
M src/backend/parser/parse_relation.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
Fix assertion failure and segmentation fault in backup code.
commit : 162ade612f1543389bd105fba82ea7e60c5b82c9
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 12 Jul 2022 11:53:29 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 12 Jul 2022 11:53:29 +0900
When a non-exclusive backup is canceled, do_pg_abort_backup() is called
and resets some variables set by pg_backup_start (pg_start_backup in v14
or before). But previously it forgot to reset the session state indicating
whether a non-exclusive backup is in progress or not in this session.
This issue could cause an assertion failure when the session running
BASE_BACKUP is terminated after it executed pg_backup_start and
pg_backup_stop (pg_stop_backup in v14 or before). Also it could cause
a segmentation fault when pg_backup_stop is called after BASE_BACKUP
in the same session is canceled.
This commit fixes the issue by making do_pg_abort_backup reset
that session state.
Back-patch to all supported branches.
Author: Fujii Masao
Reviewed-by: Kyotaro Horiguchi, Masahiko Sawada, Michael Paquier, Robert Haas
Discussion: https://postgr.es/m/3374718f-9fbf-a950-6d66-d973e027f44c@oss.nttdata.com
M src/backend/access/transam/xlog.c
Prevent BASE_BACKUP in the middle of another backup in the same session.
commit : 5630f39b31eac67a1bd56b0e6254d7724b7bbaeb
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 12 Jul 2022 09:31:57 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 12 Jul 2022 09:31:57 +0900
Multiple non-exclusive backups are able to be run conrrently in different
sessions. But, in the same session, only one non-exclusive backup can be
run at the same moment. If pg_backup_start (pg_start_backup in v14 or before)
is called in the middle of another non-exclusive backup in the same session,
an error is thrown.
However, previously, in logical replication walsender mode, even if that
walsender session had already called pg_backup_start and started
a non-exclusive backup, it could execute BASE_BACKUP command and
start another non-exclusive backup. Which caused subsequent pg_backup_stop
to throw an error because BASE_BACKUP unexpectedly reset the session state
marked by pg_backup_start.
This commit prevents BASE_BACKUP command in the middle of another
non-exclusive backup in the same session.
Back-patch to all supported branches.
Author: Fujii Masao
Reviewed-by: Kyotaro Horiguchi, Masahiko Sawada, Michael Paquier, Robert Haas
Discussion: https://postgr.es/m/3374718f-9fbf-a950-6d66-d973e027f44c@oss.nttdata.com
M src/backend/replication/basebackup.c
Re-add SPICleanup for ABI compatibility in stable branch
commit : b2c8d56618b86ba41db950e437e5abcbf085f186
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 18 Jul 2022 16:23:48 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 18 Jul 2022 16:23:48 +0200
This fixes an ABI break introduced by
cfc86f987349372dbbfc0391f9f519c0a7b27b84.
Author: Markus Wanner <markus.wanner@enterprisedb.com>
Discussion: https://www.postgresql.org/message-id/defd749a-8410-841d-1126-21398686d63d@enterprisedb.com
M src/backend/executor/spi.c
M src/include/executor/spi.h
Fix omissions in support for the "regcollation" type.
commit : 36ccca3dbac3663b5487cd5966b345009b182629
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Jul 2022 17:43:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Jul 2022 17:43:28 -0400
The patch that added regcollation doesn't seem to have been too
thorough about supporting it everywhere that other reg* types
are supported. Fix that. (The find_expr_references omission
is moderately serious, since it could result in missing expression
dependencies. The others are less exciting.)
Noted while fixing bug #17483. Back-patch to v13 where
regcollation was added.
Discussion: https://postgr.es/m/1423433.1652722406@sss.pgh.pa.us
M src/backend/catalog/dependency.c
M src/backend/utils/adt/selfuncs.c
M src/backend/utils/cache/catcache.c
postgres_fdw: set search_path to 'pg_catalog' while deparsing constants.
commit : 6230bd7df4ce1f04a350ab490a528148d25f5df9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Jul 2022 17:27:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Jul 2022 17:27:50 -0400
The motivation for this is to ensure successful transmission of the
values of constants of regconfig and other reg* types. The remote
will be reading them with search_path = 'pg_catalog', so schema
qualification is necessary when referencing objects in other schemas.
Per bug #17483 from Emmanuel Quincerot. Back-patch to all supported
versions. (There's some other stuff to do here, but it's less
back-patchable.)
Discussion: https://postgr.es/m/1423433.1652722406@sss.pgh.pa.us
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
Make dsm_impl_posix_resize more future-proof.
commit : c75b6b454ea1b981607fecce0f98697c702d8b85
author : Thomas Munro <tmunro@postgresql.org>
date : Sat, 16 Jul 2022 10:59:52 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Sat, 16 Jul 2022 10:59:52 +1200
Commit 4518c798 blocks signals for a short region of code, but it
assumed that whatever called it had the signal mask set to UnBlockSig on
entry. That may be true today (or may even not be, in extensions in the
wild), but it would be better not to make that assumption. We should
save-and-restore the caller's signal mask.
The PG_SETMASK() portability macro couldn't be used for that, which is
why it wasn't done before. But... considering that commit a65e0864
established back in 9.6 that supported POSIX systems have sigprocmask(),
and that this is POSIX-only code, there is no reason not to use standard
sigprocmask() directly to achieve that.
Back-patch to all supported releases, like 4518c798 and 80845b7c.
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CA%2BhUKGKx6Biq7_UuV0kn9DW%2B8QWcpJC1qwhizdtD9tN-fn0H0g%40mail.gmail.com
M src/backend/storage/ipc/dsm_impl.c
docs: make monitoring "phases" table titles consistent
commit : 65a0cf863270e38755ba2b6d5ae91d560128a107
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 20:01:11 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 20:01:11 -0400
Reported-by: Nitin Jadhav
Discussion: https://postgr.es/m/CAMm1aWbmTHwHKC2PERH0CCaFVPoxrtLeS8=wNuoge94qdSp3vA@mail.gmail.com
Author: Nitin Jadhav
Backpatch-through: 13
M doc/src/sgml/monitoring.sgml
doc: clarify how dropping of extensions affects dependent objs.
commit : ef9d0cf19cdb74fd9b9f833d8e42ed283e0def23
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 17:41:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 17:41:03 -0400
Clarify that functions/procedures are dropped when any extension that
depends on them is dropped.
Reported-by: David G. Johnston
Discussion: https://postgr.es/m/CAKFQuwbPSHMDGkisRUmewopweC1bFvytVqB=a=X4GFg=4ZWxPA@mail.gmail.com
Backpatch-through: 13
M doc/src/sgml/ref/alter_function.sgml
M doc/src/sgml/ref/alter_procedure.sgml
M doc/src/sgml/ref/drop_extension.sgml
pg_upgrade doc: mention that replication slots must be recreated
commit : 2d4c6437c87e6a036a163b1b4363097ee860cef0
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 16:34:30 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 16:34:30 -0400
Reported-by: Nikhil Shetty
Discussion: https://postgr.es/m/CAFpL5Vxastip0Jei-K-=7cKXTg=5sahSe5g=om=x68NOX8+PUA@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/ref/pgupgrade.sgml
doc: add documentation about ecpg Oracle-compatibility mode
commit : bf3d692deba4ffb2d54e7abf2af0d9a4969fb700
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 16:19:45 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 16:19:45 -0400
Reported-by: Takeshi Ideriha
Discussion: https://postgr.es/m/TYCPR01MB7041A157067208327D8DAAF9EAA59@TYCPR01MB7041.jpnprd01.prod.outlook.com
Backpatch-through: 11
M doc/src/sgml/ecpg.sgml
doc: clarify the behavior of identically-named savepoints
commit : 85e32877f1d747edf853ced703f6337fadb965a8
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 15:44:22 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 15:44:22 -0400
Original patch by David G. Johnston.
Reported-by: David G. Johnston
Discussion: https://postgr.es/m/CAKFQuwYQCxSSuSL18skCWG8QHFswOJ3hjovHsOZUE346i4OpVQ@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/ref/release_savepoint.sgml
M doc/src/sgml/ref/savepoint.sgml
doc: clarify that "excluded" ON CONFLICT is a single row
commit : ebf06040e52262b876069f3e515c1c09b96084b0
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 15:33:28 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 15:33:28 -0400
Original patch by David G. Johnston.
Reported-by: David G. Johnston
Discussion: https://postgr.es/m/CAKFQuwa4J0+WuO7kW1PLbjoEvzPN+Q_j+P2bXxNnCLaszY7ZdQ@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/ref/insert.sgml
doc: mention that INSERT can block because of unique indexes
commit : 2d0329b6bdd3b812d22b3d53d5e2b7bda4468a56
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 15:17:19 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 15:17:19 -0400
Initial patch by David G. Johnston.
Reported-by: David G. Johnston
Discussion: https://postgr.es/m/CAKFQuwZpbdzceO41VE-xt1Xh8rWRRfgopTAK1wL9EhCo0Am-Sw@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/ref/insert.sgml
doc: mention the pg_locks lock names in parentheses
commit : 3336b3de34e1b865af358e15a4221523221eb086
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 12:08:54 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 14 Jul 2022 12:08:54 -0400
Reported-by: Troy Frericks
Discussion: https://postgr.es/m/165653551130.665.8240515669521441325@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/mvcc.sgml
Don't clobber postmaster sigmask in dsm_impl_resize.
commit : 17aa39da50c5ac37436522fe2dd9f25a93673fdd
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 15 Jul 2022 01:23:29 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 15 Jul 2022 01:23:29 +1200
Commit 4518c798 intended to block signals in regular backends that
allocate DSM segments, but dsm_impl_resize() is also reached by
dsm_postmaster_startup(). It's not OK to clobber the postmaster's
signal mask, so only manipulate the signal mask when under the
postmaster.
Back-patch to all releases, like 4518c798.
Discussion: https://postgr.es/m/CA%2BhUKGKNpK%3D2OMeea_AZwpLg7Bm4%3DgYWk7eDjZ5F6YbozfOf8w%40mail.gmail.com
M src/backend/storage/ipc/dsm_impl.c
Block signals while allocating DSM memory.
commit : e73fe6e828d141b0ee0be8d7f58d73b3f0fad872
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 13 Jul 2022 16:16:07 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 13 Jul 2022 16:16:07 +1200
On Linux, we call posix_fallocate() on shm_open()'d memory to avoid
later potential SIGBUS (see commit 899bd785).
Based on field reports of systems stuck in an EINTR retry loop there,
there, we made it possible to break out of that loop via slightly odd
coding where the CHECK_FOR_INTERRUPTS() call was somewhat removed from
the loop (see commit 422952ee).
On further reflection, that was not a great choice for at least two
reasons:
1. If interrupts were held, the CHECK_FOR_INTERRUPTS() would do nothing
and the EINTR error would be surfaced to the user.
2. If EINTR was reported but neither QueryCancelPending nor
ProcDiePending was set, then we'd dutifully retry, but with a bit more
understanding of how posix_fallocate() works, it's now clear that you
can get into a loop that never terminates. posix_fallocate() is not a
function that can do some of the job and tell you about progress if it's
interrupted, it has to undo what it's done so far and report EINTR, and
if signals keep arriving faster than it can complete (cf recovery
conflict signals), you're stuck.
Therefore, for now, we'll simply block most signals to guarantee
progress. SIGQUIT is not blocked (see InitPostmasterChild()), because
its expected handler doesn't return, and unblockable signals like
SIGCONT are not expected to arrive at a high rate. For good measure,
we'll include the ftruncate() call in the blocked region, and add a
retry loop.
Back-patch to all supported releases.
Reported-by: Alvaro Herrera <alvherre@alvh.no-ip.org>
Reported-by: Nicola Contu <nicola.contu@gmail.com>
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20220701154105.jjfutmngoedgiad3%40alvherre.pgsql
M src/backend/storage/ipc/dsm_impl.c
Fix lock assertions in dshash.c.
commit : 7cdd0c2d7cdf08a4f8dfd8678a7b244c942e64e4
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 11 Jul 2022 14:47:16 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 11 Jul 2022 14:47:16 +1200
dshash.c previously maintained flags to be able to assert that you
didn't hold any partition lock. These flags could get out of sync with
reality in error scenarios.
Get rid of all that, and make assertions about the locks themselves
instead. Since LWLockHeldByMe() loops internally, we don't want to put
that inside another loop over all partition locks. Introduce a new
debugging-only interface LWLockAnyHeldByMe() to avoid that.
This problem was noted by Tom and Andres while reviewing changes to
support the new shared memory stats system, and later showed up in
reality while working on commit 389869af.
Back-patch to 11, where dshash.c arrived.
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Reported-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Reviewed-by: Zhihong Yu <zyu@yugabyte.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20220311012712.botrpsikaufzteyt@alap3.anarazel.de
Discussion: https://postgr.es/m/CA%2BhUKGJ31Wce6HJ7xnVTKWjFUWQZPBngxfJVx4q0E98pDr3kAw%40mail.gmail.com
M src/backend/lib/dshash.c
M src/backend/storage/lmgr/lwlock.c
M src/include/storage/lwlock.h
Fix \watch's interaction with libedit on ^C.
commit : e5b5b4448ce0981a7a89a8c43df77d71bfa9cc96
author : Thomas Munro <tmunro@postgresql.org>
date : Sun, 10 Jul 2022 16:30:03 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Sun, 10 Jul 2022 16:30:03 +1200
When you hit ^C, the terminal driver in Unix-like systems echoes "^C" as
well as sending an interrupt signal (depending on stty settings). At
least libedit (but maybe also libreadline) is then confused about the
current cursor location, and corrupts the display if you try to scroll
back. Fix, by moving to a new line before the next prompt is displayed.
Back-patch to all supported released.
Author: Pavel Stehule <pavel.stehule@gmail.com>
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/3278793.1626198638%40sss.pgh.pa.us
M src/bin/psql/command.c
doc: add examples for array_length() and jsonb_array_length()
commit : 49d296d8e8723b7517ecc074be4694349d6a1cd2
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 8 Jul 2022 20:23:34 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 8 Jul 2022 20:23:34 -0400
The examples show the output of array_length() and jsonb_array_length()
for empty arrays.
Discussion: https://postgr.es/m/CAKFQuwaoBmRuWdMLzLHDCFDJDX3wvfQ7egAF0bpik_BFgG1KWg@mail.gmail.com
Author: David G. Johnston
Backpatch-through: 13
M doc/src/sgml/func.sgml
doc: add pg_prewarm example
commit : 12f56b6a70ca06acd394f37a965e4814e8472373
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 8 Jul 2022 18:36:27 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 8 Jul 2022 18:36:27 -0400
Discussion: https://postgr.es/m/20220618085541.ezxdaljlpo6x7msc@home-desktop
Author: Dong Wook Lee
Backpatch-through: 11
M doc/src/sgml/pgprewarm.sgml
Fix alias matching in transformLockingClause().
commit : f890223bc3c45f78774d9b042b62f529eb434aa9
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 7 Jul 2022 13:08:00 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 7 Jul 2022 13:08:00 +0100
When locking a specific named relation for a FOR [KEY] UPDATE/SHARE
clause, transformLockingClause() finds the relation to lock by
scanning the rangetable for an RTE with a matching eref->aliasname.
However, it failed to account for the visibility rules of a join RTE.
If a join RTE doesn't have a user-supplied alias, it will have a
generated eref->aliasname of "unnamed_join" that is not visible as a
relation name in the parse namespace. Such an RTE needs to be skipped,
otherwise it might be found in preference to a regular base relation
with a user-supplied alias of "unnamed_join", preventing it from being
locked.
In addition, if a join RTE doesn't have a user-supplied alias, but
does have a join_using_alias, then the RTE needs to be matched using
that alias rather than the generated eref->aliasname, otherwise a
misleading "relation not found" error will be reported rather than a
"join cannot be locked" error.
Backpatch all the way, except for the second part which only goes back
to 14, where JOIN USING aliases were added.
Dean Rasheed, reviewed by Tom Lane.
Discussion: https://postgr.es/m/CAEZATCUY_KOBnqxbTSPf=7fz9HWPnZ5Xgb9SwYzZ8rFXe7nb=w@mail.gmail.com
M src/backend/parser/analyze.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
BRIN: improve documentation on summarization
commit : d2323570ad339330c9deaf3304750096c9f6a98a
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 5 Jul 2022 13:38:26 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 5 Jul 2022 13:38:26 +0200
The existing wording wasn't clear enough and some details weren't
anywhere, such as the fact that autosummarization is off by default.
Improve.
Authors: Roberto Mello, Jaime Casanova, Justin Pryzby, Álvaro Herrera
Discussion: https://postgr.es/m/CAKz==bK_NoJytRyQfX8K-erCW3Ff7--oGYpiB8+ePVS7dRVW_A@mail.gmail.com
Discussion: https://postgr.es/m/20220224193520.GY9008@telsasoft.com
M doc/src/sgml/brin.sgml
M doc/src/sgml/ref/create_index.sgml
Remove %error-verbose directive from jsonpath parser
commit : 03cefe81484d563a7165e8fa57a03a33d4c5c188
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 3 Jul 2022 17:08:25 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 3 Jul 2022 17:08:25 -0400
None of the other bison parsers contains this directive, and it gives
rise to some unfortunate and impenetrable messages, so just remove it.
Backpatch to release 12, where it was introduced.
Per gripe from Erik Rijkers
Discussion: https://postgr.es/m/ba069ce2-a98f-dc70-dc17-2ccf2a9bf7c7@xs4all.nl
M src/backend/utils/adt/jsonpath_gram.y
M src/test/regress/expected/jsonpath.out
Fix previous commit's ecpg_clocale for ppc Darwin.
commit : 97b005f3fb1b32581493e0e6e7fca028d9896207
author : Noah Misch <noah@leadboat.com>
date : Sat, 2 Jul 2022 21:03:19 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 2 Jul 2022 21:03:19 -0700
Per buildfarm member prairiedog, this platform rejects uninitialized
global variables in shared libraries. Back-patch to v10, like the
addition of the variable.
Reviewed by Tom Lane.
Discussion: https://postgr.es/m/20220703030619.GB2378460@rfd.leadboat.com
M src/interfaces/ecpg/ecpglib/connect.c
ecpglib: call newlocale() once per process.
commit : b4d7e92bd5354c78c0d0405d08d85b73d20f50f7
author : Noah Misch <noah@leadboat.com>
date : Sat, 2 Jul 2022 13:00:30 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 2 Jul 2022 13:00:30 -0700
ecpglib has been calling it once per SQL query and once per EXEC SQL GET
DESCRIPTOR. Instead, if newlocale() has not succeeded before, call it
while establishing a connection. This mitigates three problems:
- If newlocale() failed in EXEC SQL GET DESCRIPTOR, the command silently
proceeded without the intended locale change.
- On AIX, each newlocale()+freelocale() cycle leaked memory.
- newlocale() CPU usage may have been nontrivial.
Fail the connection attempt if newlocale() fails. Rearrange
ecpg_do_prologue() to validate the connection before its uselocale().
The sort of program that may regress is one running in an environment
where newlocale() fails. If that program establishes connections
without running SQL statements, it will stop working in response to this
change. I'm betting against the importance of such an ECPG use case.
Most SQL execution (any using ECPGdo()) has long required newlocale()
success, so there's little a connection could do without newlocale().
Back-patch to v10 (all supported versions).
Reviewed by Tom Lane. Reported by Guillaume Lelarge.
Discussion: https://postgr.es/m/20220101074055.GA54621@rfd.leadboat.com
M src/interfaces/ecpg/ecpglib/connect.c
M src/interfaces/ecpg/ecpglib/descriptor.c
M src/interfaces/ecpg/ecpglib/ecpglib_extern.h
M src/interfaces/ecpg/ecpglib/execute.c
Harden dsm_impl.c against unexpected EEXIST.
commit : b436047dc6920516f878b65f7b7c3e0e27050025
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 1 Jul 2022 12:05:52 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 1 Jul 2022 12:05:52 +1200
Previously, we trusted the OS not to report EEXIST unless we'd passed in
IPC_CREAT | IPC_EXCL or O_CREAT | O_EXCL, as appropriate. Solaris's
shm_open() can in fact do that, causing us to crash because we didn't
ereport and then we blithely assumed the mapping was successful.
Let's treat EEXIST just like any other error, unless we're actually
trying to create a new segment. This applies to shm_open(), where this
behavior has been seen, and also to the equivalent operations for our
sysv and mmap modes just on principle.
Based on the underlying reason for the error, namely contention on a
lock file managed by Solaris librt for each distinct name, this problem
is only likely to happen on 15 and later, because the new shared memory
stats system produces shm_open() calls for the same path from
potentially large numbers of backends concurrently during
authentication. Earlier releases only shared memory segments between a
small number of parallel workers under one Gather node. You could
probably hit it if you tried hard enough though, and we should have been
more defensive in the first place. Therefore, back-patch to all
supported releases.
Per build farm animal margay. This isn't the end of the story, though,
it just changes random crashes into random "File exists" errors; more
work needed for a green build farm.
Reviewed-by: Robert Haas <robertmhaas@gmail.com>
Discussion: https://postgr.es/m/CA%2BhUKGKqKrCV5xKWfh9rnm%3Do%3DDwZLTLtnsj_XpUi9g5%3DV%2B9oyg%40mail.gmail.com
M src/backend/storage/ipc/dsm_impl.c
Fix visibility check when XID is committed in CLOG but not in procarray.
commit : 7ba325fd7fd450688afd2f80d19cad060feb51b5
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Jun 2022 08:21:08 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Jun 2022 08:21:08 +0300
TransactionIdIsInProgress had a fast path to return 'false' if the
single-item CLOG cache said that the transaction was known to be
committed. However, that was wrong, because a transaction is first
marked as committed in the CLOG but doesn't become visible to others
until it has removed its XID from the proc array. That could lead to an
error:
ERROR: t_xmin is uncommitted in tuple to be updated
or for an UPDATE to go ahead without blocking, before the previous
UPDATE on the same row was made visible.
The window is usually very short, but synchronous replication makes it
much wider, because the wait for synchronous replica happens in that
window.
Another thing that makes it hard to hit is that it's hard to get such
a commit-in-progress transaction into the single item CLOG cache.
Normally, if you call TransactionIdIsInProgress on such a transaction,
it determines that the XID is in progress without checking the CLOG
and without populating the cache. One way to prime the cache is to
explicitly call pg_xact_status() on the XID. Another way is to use a
lot of subtransactions, so that the subxid cache in the proc array is
overflown, making TransactionIdIsInProgress rely on pg_subtrans and
CLOG checks.
This has been broken ever since it was introduced in 2008, but the race
condition is very hard to hit, especially without synchronous
replication. There were a couple of reports of the error starting from
summer 2021, but no one was able to find the root cause then.
TransactionIdIsKnownCompleted() is now unused. In 'master', remove it,
but I left it in place in backbranches in case it's used by extensions.
Also change pg_xact_status() to check TransactionIdIsInProgress().
Previously, it only checked the CLOG, and returned "committed" before
the transaction was actually made visible to other queries. Note that
this also means that you cannot use pg_xact_status() to reproduce the
bug anymore, even if the code wasn't fixed.
Report and analysis by Konstantin Knizhnik. Patch by Simon Riggs, with
the pg_xact_status() change added by me.
Author: Simon Riggs
Reviewed-by: Andres Freund
Discussion: https://www.postgresql.org/message-id/flat/4da7913d-398c-e2ad-d777-f752cf7f0bbb%40garret.ru
M src/backend/access/transam/transam.c
M src/backend/storage/ipc/procarray.c
M src/backend/utils/adt/xid8funcs.c
Fix PostgreSQL::Test aliasing for Perl v5.10.1.
commit : aa1845cdd6979aa0a7f51f716712c71e84920313
author : Noah Misch <noah@leadboat.com>
date : Sat, 25 Jun 2022 14:15:56 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 25 Jun 2022 14:15:56 -0700
This Perl segfaults if a declaration of the to-be-aliased package
precedes the aliasing itself. Per buildfarm members lapwing and wrasse.
Like commit 20911775de4ab7ac3ecc68bd714cb3ed0fd68b6a, back-patch to v10
(all supported versions).
Discussion: https://postgr.es/m/20220625171533.GA2012493@rfd.leadboat.com
M src/test/perl/PostgreSQL/Test/Cluster.pm
M src/test/perl/PostgreSQL/Test/Utils.pm
CREATE INDEX: use the original userid for more ACL checks.
commit : 8782ce49e4d0c8886cd09d824dd55f741f709f8f
author : Noah Misch <noah@leadboat.com>
date : Sat, 25 Jun 2022 09:07:41 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 25 Jun 2022 09:07:41 -0700
Commit a117cebd638dd02e5c2e791c25e43745f233111b used the original userid
for ACL checks located directly in DefineIndex(), but it still adopted
the table owner userid for more ACL checks than intended. That broke
dump/reload of indexes that refer to an operator class, collation, or
exclusion operator in a schema other than "public" or "pg_catalog".
Back-patch to v10 (all supported versions), like the earlier commit.
Nathan Bossart and Noah Misch
Discussion: https://postgr.es/m/f8a4105f076544c180a87ef0c4822352@stmuk.bayern.de
M contrib/citext/Makefile
A contrib/citext/expected/create_index_acl.out
A contrib/citext/sql/create_index_acl.sql
M src/backend/commands/indexcmds.c
For PostgreSQL::Test compatibility, alias entire package symbol tables.
commit : e8f037a2df9b6f5936c7958dcc18a2b8d609f410
author : Noah Misch <noah@leadboat.com>
date : Sat, 25 Jun 2022 09:07:44 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 25 Jun 2022 09:07:44 -0700
Remove the need to edit back-branch-specific code sites when
back-patching the addition of a PostgreSQL::Test::Utils symbol. Replace
per-symbol, incomplete alias lists. Give old and new package names the
same EXPORT and EXPORT_OK semantics. Back-patch to v10 (all supported
versions).
Reviewed by Andrew Dunstan.
Discussion: https://postgr.es/m/20220622072144.GD4167527@rfd.leadboat.com
M src/test/perl/PostgreSQL/Test/Cluster.pm
M src/test/perl/PostgreSQL/Test/Utils.pm
M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
Fix memory leak due to LogicalRepRelMapEntry.attrmap.
commit : 3a6ef0cdf31191309ec586b04034f6dcd2542bcc
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 23 Jun 2022 09:02:16 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 23 Jun 2022 09:02:16 +0530
When rebuilding the relation mapping on subscribers, we were not releasing
the attribute mapping's memory which was no longer required.
The attribute mapping used in logical tuple conversion was refactored in
PG13 (by commit e1551f96e6) but we forgot to update the related code that
frees the attribute map.
Author: Hou Zhijie
Reviewed-by: Amit Langote, Amit Kapila, Shi yu
Backpatch-through: 10, where it was introduced
Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com
M src/backend/replication/logical/relation.c
doc: improve wording of plpgsql RAISE format text
commit : 9adc4cd3d678f07f749ab3b91016e272fc7d186d
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 22 Jun 2022 16:59:53 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 22 Jun 2022 16:59:53 -0400
Reported-by: pg@kirasoft.com
Discussion: https://postgr.es/m/165455351426.573551.7050474465030525109@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/plpgsql.sgml
doc: clarify wording about phantom reads
commit : 3485f8d03eb8cdaa1100472fd36761b1a4b82337
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 22 Jun 2022 14:33:26 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 22 Jun 2022 14:33:26 -0400
Reported-by: akhilhello@gmail.com
Discussion: https://postgr.es/m/165222922369.669.10475917322916060899@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/high-availability.sgml
M doc/src/sgml/mvcc.sgml
Fix SPI's handling of errors during transaction commit.
commit : cfc86f987349372dbbfc0391f9f519c0a7b27b84
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 Jun 2022 12:12:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 Jun 2022 12:12:00 -0400
SPI_commit previously left it up to the caller to recover from any error
occurring during commit. Since that's complicated and requires use of
low-level xact.c facilities, it's not too surprising that no caller got
it right. Let's move the responsibility for cleanup into spi.c. Doing
that requires redefining SPI_commit as starting a new transaction, so
that it becomes equivalent to SPI_commit_and_chain except that you get
default transaction characteristics instead of preserving the prior
transaction's characteristics. We can make this pretty transparent
API-wise by redefining SPI_start_transaction() as a no-op. Callers
that expect to do something in between might be surprised, but
available evidence is that no callers do so.
Having made that API redefinition, we can fix this mess by having
SPI_commit[_and_chain] trap errors and start a new, clean transaction
before re-throwing the error. Likewise for SPI_rollback[_and_chain].
Some cleanup is also needed in AtEOXact_SPI, which was nowhere near
smart enough to deal with SPI contexts nested inside a committing
context.
While plperl and pltcl need no changes beyond removing their now-useless
SPI_start_transaction() calls, plpython needs some more work because it
hadn't gotten the memo about catching commit/rollback errors in the
first place. Such an error resulted in longjmp'ing out of the Python
interpreter, which leaks Python stack entries at present and is reported
to crash Python 3.11 altogether. Add the missing logic to catch such
errors and convert them into Python exceptions.
This is a back-patch of commit 2e517818f. That's now aged long enough
to reduce the concerns about whether it will break something, and we
do need to ensure that supported branches will work with Python 3.11.
Peter Eisentraut and Tom Lane
Discussion: https://postgr.es/m/3375ffd8-d71c-2565-e348-a597d6e739e3@enterprisedb.com
Discussion: https://postgr.es/m/17416-ed8fe5d7213d6c25@postgresql.org
M doc/src/sgml/spi.sgml
M src/backend/executor/spi.c
M src/backend/tcop/postgres.c
M src/backend/utils/mmgr/portalmem.c
M src/include/executor/spi.h
M src/pl/plperl/expected/plperl_transaction.out
M src/pl/plperl/plperl.c
M src/pl/plperl/sql/plperl_transaction.sql
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpython/expected/plpython_transaction.out
M src/pl/plpython/plpy_plpymodule.c
M src/pl/plpython/plpy_spi.c
M src/pl/plpython/plpy_spi.h
M src/pl/plpython/sql/plpython_transaction.sql
M src/pl/tcl/expected/pltcl_transaction.out
M src/pl/tcl/pltcl.c
M src/pl/tcl/sql/pltcl_transaction.sql
Fix stale values in partition map entries on subscribers.
commit : 419c72715172ed787e36fd66a85b2a571340bd79
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Jun 2022 15:12:52 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Jun 2022 15:12:52 +0530
We build the partition map entries on subscribers while applying the
changes for update/delete on partitions. The component relation in each
entry is closed after its use so we need to update it on successive use of
cache entries.
This problem was there since the original commit f1ac27bfda that
introduced this code but we didn't notice it till the recent commit
26b3455afa started to use the component relation of partition map cache
entry.
Reported-by: Tom Lane, as per buildfarm
Author: Amit Langote, Hou Zhijie
Reviewed-by: Amit Kapila, Shi Yu
Backpatch-through: 13, where it was introduced
Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com
M src/backend/replication/logical/relation.c
Fix partition table's REPLICA IDENTITY checking on the subscriber.
commit : 5f113d60e9982b8d5a8c9b2e85dc82330d3c683a
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Jun 2022 07:48:02 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Jun 2022 07:48:02 +0530
In logical replication, we will check if the target table on the
subscriber is updatable by comparing the replica identity of the table on
the publisher with the table on the subscriber. When the target table is a
partitioned table, we only check its replica identity but not for the
partition tables. This leads to assertion failure while applying changes
for update/delete as we expect those to succeed only when the
corresponding partition table has a primary key or has a replica
identity defined.
Fix it by checking the replica identity of the partition table while
applying changes.
Reported-by: Shi Yu
Author: Shi Yu, Hou Zhijie
Reviewed-by: Amit Langote, Amit Kapila
Backpatch-through: 13, where it was introduced
Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com
M src/backend/replication/logical/relation.c
M src/backend/replication/logical/worker.c
M src/test/subscription/t/013_partition.pl
Fix data inconsistency between publisher and subscriber.
commit : 1f9a7738eb84f341a9b39689f33c887d1ef39487
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 16 Jun 2022 08:24:22 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 16 Jun 2022 08:24:22 +0530
We were not updating the partition map cache in the subscriber even when
the corresponding remote rel is changed. Due to this data was getting
incorrectly replicated for partition tables after the publisher has
changed the table schema.
Fix it by resetting the required entries in the partition map cache after
receiving a new relation mapping from the publisher.
Reported-by: Shi Yu
Author: Shi Yu, Hou Zhijie
Reviewed-by: Amit Langote, Amit Kapila
Backpatch-through: 13, where it was introduced
Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com
M src/backend/replication/logical/relation.c
M src/backend/replication/logical/worker.c
M src/include/replication/logicalrelation.h
M src/test/subscription/t/013_partition.pl
Fix cache look-up failures while applying changes in logical replication.
commit : 16f5a8da76f21576987790df828082cb7bb1bdad
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 15 Jun 2022 10:16:35 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 15 Jun 2022 10:16:35 +0530
While building a new attrmap which maps partition attribute numbers to
remoterel's, we incorrectly update the map for dropped column attributes.
Later, it caused cache look-up failure when we tried to use the map to
fetch the information about attributes.
This also fixes the partition map cache invalidation which was using the
wrong type cast to fetch the entry. We were using stale partition map
entry after invalidation which leads to the assertion or cache look-up
failure.
Reported-by: Shi Yu
Author: Hou Zhijie, Shi Yu
Reviewed-by: Amit Langote, Amit Kapila
Backpatch-through: 13, where it was introduced
Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com
M src/backend/replication/logical/relation.c
M src/test/subscription/t/013_partition.pl
Avoid ecpglib core dump with out-of-order operations.
commit : 12b8fb34a933456ca762c98bc2047e608b7a1079
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Jun 2022 18:16:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Jun 2022 18:16:46 -0400
If an application executed operations like EXEC SQL PREPARE
without having first established a database connection, it could
get a core dump instead of the expected clean failure. This
occurred because we did "pthread_getspecific(actual_connection_key)"
without ever having initialized the TSD key actual_connection_key.
The results of that are probably platform-specific, but at least
on Linux it often leads to a crash.
To fix, add calls to ecpg_pthreads_init() in the code paths that
might use actual_connection_key uninitialized. It's harmless
(and hopefully inexpensive) to do that more than once.
Per bug #17514 from Okano Naoki. The problem's ancient, so
back-patch to all supported branches.
Discussion: https://postgr.es/m/17514-edd4fad547c5692c@postgresql.org
M src/interfaces/ecpg/ecpglib/connect.c
Doc: clarify the default collation behavior of domains.
commit : d6d9ea0a468bd5a8bf0feb98e41f1ecb4b8a173d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Jun 2022 17:47:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Jun 2022 17:47:09 -0400
The previous wording was "the underlying data type's default collation
is used", which is wrong or at least misleading. The domain inherits
the base type's collation behavior, which if "default" actually can
mean that we use some non-default collation obtained from elsewhere.
Per complaint from Jian He.
Discussion: https://postgr.es/m/CACJufxHMR8_4WooDPjjvEdaxB2hQ5a49qthci8fpKP0MKemVRQ@mail.gmail.com
M doc/src/sgml/ref/create_domain.sgml
Revert "Fix psql's single transaction mode on client-side errors with -c/-f switches".
commit : 3f7f06738529f4a71cf33c79654954e6178972a1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Jun 2022 16:34:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Jun 2022 16:34:25 -0400
This reverts commits a04ccf6df et al. in the back branches only.
There was some disagreement already over whether to back-patch
157f8739a, on the grounds that it is the sort of behavioral
change that we don't like to back-patch. Furthermore, it now
looks like the logic needs some more work, which we don't have
time for before the upcoming 14.4 release. Revert for now, and
perhaps reconsider later.
Discussion: https://postgr.es/m/17504-76b68018e130415e@postgresql.org
M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/startup.c
Un-break whole-row Vars referencing domain-over-composite types.
commit : 254cd7f31f60f02de0548c8dcdc2c402c0cf02d8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Jun 2022 10:35:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Jun 2022 10:35:57 -0400
In commit ec62cb0aa, I foolishly replaced ExecEvalWholeRowVar's
lookup_rowtype_tupdesc_domain call with just lookup_rowtype_tupdesc,
because I didn't see how a domain could be involved there, and
there were no regression test cases to jog my memory. But the
existing code was correct, so revert that change and add a test
case showing why it's necessary. (Note: per comment in struct
DatumTupleFields, it is correct to produce an output tuple that's
labeled with the base composite type, not the domain; hence just
blindly looking through the domain is correct here.)
Per bug #17515 from Dan Kubb. Back-patch to v11 where domains over
composites became a thing.
Discussion: https://postgr.es/m/17515-a24737438363aca0@postgresql.org
M src/backend/executor/execExprInterp.c
M src/test/regress/expected/domain.out
M src/test/regress/sql/domain.sql
Doc: copy-edit "jsonb Indexing" section.
commit : 2bc7dffa300819e44051a80cda0edcffbf673ea8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Jun 2022 12:01:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Jun 2022 12:01:51 -0400
The patch introducing jsonpath dropped a para about that between
two related examples, and didn't bother updating the introductory
sentences that it falsified. The grammar was pretty shaky as well.
M doc/src/sgml/json.sgml
Fix whitespace
commit : 925816684a522c0fb26d986540cde963aefb5c43
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 8 Jun 2022 13:42:39 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 8 Jun 2022 13:42:39 +0200
M src/test/perl/PostgreSQL/Test/Cluster.pm
Fix off-by-one loop termination condition in pg_stat_get_subscription().
commit : a36196972b77228882cab7838eed52c1a9154e4a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Jun 2022 15:34:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Jun 2022 15:34:30 -0400
pg_stat_get_subscription scanned one more LogicalRepWorker array entry
than is really allocated. In the worst case this could lead to SIGSEGV,
if the LogicalRepCtx data structure is near the end of shared memory.
That seems quite unlikely though (thanks to the ordering of calls in
CreateSharedMemoryAndSemaphores) and we've heard no field reports of it.
A more likely misbehavior is one row of garbage data in the function's
result, but even that is not real likely because of the check that the
pid field matches some live backend.
Report and fix by Kuntal Ghosh. This bug is old, so back-patch
to all supported branches.
Discussion: https://postgr.es/m/CAGz5QCJykEDzW6jQK6Yz7Qh_PMtD=95de_7QoocbVR2Qy8hWZA@mail.gmail.com
M src/backend/replication/logical/launcher.c
Don't fail on libpq-generated error reports in ecpg_raise_backend().
commit : 16d68007cd7400061bd499b92eb80fbb9798362c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Jun 2022 11:20:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Jun 2022 11:20:21 -0400
An error PGresult generated by libpq itself, such as a report of
connection loss, won't have broken-down error fields.
ecpg_raise_backend() blithely assumed that PG_DIAG_MESSAGE_PRIMARY
would always be present, and would end up passing a NULL string
pointer to snprintf when it isn't. That would typically crash
before 3779ac62d, and it would fail to provide a useful error report
in any case. Best practice is to substitute PQerrorMessage(conn)
in such cases, so do that.
Per bug #17421 from Masayuki Hirose. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/17421-790ff887e3188874@postgresql.org
M src/interfaces/ecpg/ecpglib/error.c
Fix psql's single transaction mode on client-side errors with -c/-f switches
commit : b364cfdfaf6b24e18c8f6017111306259f87c0f4
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 6 Jun 2022 11:07:27 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 6 Jun 2022 11:07:27 +0900
psql --single-transaction is able to handle multiple -c and -f switches
in a single transaction since d5563d7d, but this had the surprising
behavior of forcing a transaction COMMIT even if psql failed with an
error in the client (for example incorrect path given to \copy), which
would generate an error, but still commit any changes that were already
applied in the backend. This commit makes the behavior more consistent,
by enforcing a transaction ROLLBACK if any commands fail, both
client-side and backend-side, so as no changes are applied if one error
happens in any of them.
Some tests are added on HEAD to provide some coverage about all that.
Backend-side errors are unreliable as IPC::Run can complain on SIGPIPE
if psql quits before reading a query result, but that should work
properly in the case where any errors come from psql itself, which is
what the original report is about.
Reported-by: Christoph Berg
Author: Kyotaro Horiguchi, Michael Paquier
Discussion: https://postgr.es/m/17504-76b68018e130415e@postgresql.org
Backpatch-through: 10
M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/startup.c
Doc: improve example for intarray's uniq() function.
commit : 9985139046c3aad4214cdd490e7bcdfefc9290d3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Jun 2022 13:54:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Jun 2022 13:54:53 -0400
The previous entry invited confusion between what uniq() does
by itself and what it does when combined with sort(). The latter
usage is pretty useful so we should show it, but add an additional
example to clarify the results of uniq() alone.
Per suggestion from Martin Kalcher. Back-patch to v13, where
we switched to formatting that supports multiple examples.
Discussion: https://postgr.es/m/165407884456.573551.8779012279828726162@wrigleys.postgresql.org
M doc/src/sgml/intarray.sgml
Doc: fix incorrect bit-reversal in example of macaddr formatting.
commit : 54299b9ce7ccea885c06d6833ec04b3b06a82788
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Jun 2022 11:51:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Jun 2022 11:51:37 -0400
Will Mortensen (minor additional copy-editing by me)
Discussion: https://postgr.es/m/CAMpnoC5Y6jiZHSA82FG+e_AqkwMg-i94EYqs1C_9kXXFc3_3Yw@mail.gmail.com
M doc/src/sgml/datatype.sgml
Doc: Further fix CREATE FOREIGN TABLE synopsis.
commit : de61a9cbaa95662b31e673a0a22696946c95ba38
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 2 Jun 2022 18:00:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 2 Jun 2022 18:00:03 +0900
This patch fixes the partitioning synopsis in the Parameters section in
the CREATE FOREIGN TABLE documentation. Follow-up for commit ce21a36cf.
Back-patch to v11 where default partition was introduced.
Reviewed by Amit Langote and Robert Haas.
Discussion: https://postgr.es/m/CAPmGK17U5jEqVZuo3r38wB0VFWomEtJCBGn_h92HQzQ2sP-49Q%40mail.gmail.com
M doc/src/sgml/ref/create_foreign_table.sgml
Silence compiler warnings from some older compilers.
commit : 60ca2e8418a14b531f684723d08639997afc0d6f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Jun 2022 17:21:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Jun 2022 17:21:45 -0400
Since a117cebd6, some older gcc versions issue "variable may be used
uninitialized in this function" complaints for brin_summarize_range.
Silence that using the same coding pattern as in bt_index_check_internal;
arguably, a117cebd6 had too narrow a view of which compilers might give
trouble.
Nathan Bossart and Tom Lane. Back-patch as the previous commit was.
Discussion: https://postgr.es/m/20220601163537.GA2331988@nathanxps13
M contrib/amcheck/verify_nbtree.c
M src/backend/access/brin/brin.c
Fix pl/perl test case so it will still work under Perl 5.36.
commit : eeac7dd9ff76ee7ea1feb2dd6004c5d92c6caca5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Jun 2022 16:15:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/564579.1654093326@sss.pgh.pa.us
M src/pl/plperl/expected/plperl.out
M src/pl/plperl/sql/plperl.sql
Doc: mention limitation of the number of resultset columns
commit : e6bd7aafc82d5f7ae1cb4bf15ce47d2ad12e5dd3
author : David Rowley <drowley@postgresql.org>
date : Wed, 1 Jun 2022 12:46:54 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 1 Jun 2022 12:46:54 +1200
The PostgreSQL limitations section of the documents mentioned the limit
on the number of columns that can exist in a table. Users might be
surprised to find that there's also a limit on the number of columns that
can exist in a targetlist. Users may experience restrictions which
surprise them if they happened to select a large number of columns from
several tables with many columns. Here we document that there is a
limitation on this and mention what that limit actually is.
Wording proposal by Alvaro Herrera
Reported-by: Vladimir Sitnikov
Author: Dave Crammer
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/CAB=Je-E18aTYpNqje4mT0iEADpeGLSzwUvo3H9kRRuDdsNo4aQ@mail.gmail.com
Backpatch-through: 12, where the limitations section was added
M doc/src/sgml/limits.sgml
Ensure ParseTzFile() closes the input file after failing.
commit : c73748b68a0e5f80d9014af748b194f728a074d3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 May 2022 14:47:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 May 2022 14:47:44 -0400
We hadn't noticed this because (a) few people feed invalid
timezone abbreviation files to the server, and (b) in typical
scenarios guc.c would throw ereport(ERROR) and then transaction
abort handling would silently clean up the leaked file reference.
However, it was possible to observe file leakage warnings if one
breaks an already-active abbreviation file, because guc.c does
not throw ERROR when loading supposedly-validated settings during
session start or SIGHUP processing.
Report and fix by Kyotaro Horiguchi (cosmetic adjustments by me)
Discussion: https://postgr.es/m/20220530.173740.748502979257582392.horikyota.ntt@gmail.com
M src/backend/utils/misc/tzparser.c
Doc: fix mention of pg_dump's minimum supported server version.
commit : cbd4c5a183521729eb652138eebd2d2a38bdeca5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 May 2022 12:14:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 May 2022 12:14:02 -0400
runtime.sgml contains a passing reference to the minimum server
version that pg_dump[all] can dump from. That was 7.0 for many
years, but when 64f3524e2 raised it to 8.0, we missed updating this
bit. Then when 30e7c175b raised it to 9.2, we missed it again.
Given that track record, I'm not too hopeful that we'll remember
to fix this in future changes ... but for now, make the docs match
reality in each branch.
Noted by Daniel Westermann.
Discussion: https://postgr.es/m/GV0P278MB041917EB3E2FE8704B5AE2C6D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM
M doc/src/sgml/runtime.sgml
doc: Reword description of roles able to view track_activities's info
commit : 938548b7545857153190d6509289348051de4892
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 30 May 2022 10:50:38 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 30 May 2022 10:50:38 +0900
The information generated when track_activities is accessible to
superusers, roles with the privileges of pg_read_all_stats, as well as
roles one has the privileges of. The original text did not outline the
last point, while the change done in ac1ae47 was unclear about the
second point.
Per discussion with Nathan Bossart.
Discussion: https://postgr.es/m/20220521185743.GA886636@nathanxps13
Backpatch-through: 10
M doc/src/sgml/config.sgml
Handle NULL for short descriptions of custom GUC variables
commit : 1e6802990cdd223ac9d175cd804d6a475aebe5b6
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 28 May 2022 12:12:51 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 28 May 2022 12:12:51 +0900
If a short description is specified as NULL in one of the various
DefineCustomXXXVariable() functions available to external modules to
define a custom parameter, SHOW ALL would crash. This change teaches
SHOW ALL to properly handle NULL short descriptions, as well as any code
paths that manipulate it, to gain in flexibility. Note that
help_config.c was already able to do that, when describing a set of GUCs
for postgres --describe-config.
Author: Steve Chavez
Reviewed by: Nathan Bossart, Andres Freund, Michael Paquier, Tom Lane
Discussion: https://postgr.es/m/CAGRrpzY6hO-Kmykna_XvsTv8P2DshGiU6G3j8yGao4mk0CqjHA%40mail.gmail.com
Backpatch-through: 10
M src/backend/utils/misc/guc.c
Remove misguided SSL key file ownership check in libpq.
commit : 9e3dbc6fd9a38cd7c72289f7facd639976484e45
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 May 2022 14:14:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 May 2022 14:14:05 -0400
Commits a59c79564 et al. tried to sync libpq's SSL key file
permissions checks with what we've used for years in the backend.
We did not intend to create any new failure cases, but it turns out
we did: restricting the key file's ownership breaks cases where the
client is allowed to read a key file despite not having the identical
UID. In particular a client running as root used to be able to read
someone else's key file; and having seen that I suspect that there are
other, less-dubious use cases that this restriction breaks on some
platforms.
We don't really need an ownership check, since if we can read the key
file despite its having restricted permissions, it must have the right
ownership --- under normal conditions anyway, and the point of this
patch is that any additional corner cases where that works should be
deemed allowable, as they have been historically. Hence, just drop
the ownership check, and rearrange the permissions check to get rid
of its faulty assumption that geteuid() can't be zero. (Note that the
comparable backend-side code doesn't have to cater for geteuid() == 0,
since the server rejects that very early on.)
This does have the end result that the permissions safety check used
for a root user's private key file is weaker than that used for
anyone else's. While odd, root really ought to know what she's doing
with file permissions, so I think this is acceptable.
Per report from Yogendra Suralkar. Like the previous patch,
back-patch to all supported branches.
Discussion: https://postgr.es/m/MW3PR15MB3931DF96896DC36D21AFD47CA3D39@MW3PR15MB3931.namprd15.prod.outlook.com
M src/backend/libpq/be-secure-common.c
M src/interfaces/libpq/fe-secure-openssl.c
In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff.
commit : 036cffbcae9b8e1b8a17ebe5203cb596f82b5989
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 26 May 2022 12:55:00 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 26 May 2022 12:55:00 -0400
Foreign tables can be partitioned, but previous documentation commits
left the syntax synopsis both incomplete and incorrect.
Justin Pryzby and Amit Langote
Discussion: http://postgr.es/m/20220521130922.GX19626@telsasoft.com
M doc/src/sgml/ref/create_foreign_table.sgml
Show 'AS "?column?"' explicitly when it's important.
commit : fefd5463173a6ca598ae206b13a505297d9efecb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 May 2022 14:45:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 May 2022 14:45:58 -0400
ruleutils.c was coded to suppress the AS label for a SELECT output
expression if the column name is "?column?", which is the parser's
fallback if it can't think of something better. This is fine, and
avoids ugly clutter, so long as (1) nothing further up in the parse
tree relies on that column name or (2) the same fallback would be
assigned when the rule or view definition is reloaded. Unfortunately
(2) is far from certain, both because ruleutils.c might print the
expression in a different form from how it was originally written
and because FigureColname's rules might change in future releases.
So we shouldn't rely on that.
Detecting exactly whether there is any outer-level use of a SELECT
column name would be rather expensive. This patch takes the simpler
approach of just passing down a flag indicating whether there *could*
be any outer use; for example, the output column names of a SubLink
are not referenceable, and we also do not care about the names exposed
by the right-hand side of a setop. This is sufficient to suppress
unwanted clutter in all but one case in the regression tests. That
seems like reasonable evidence that it won't be too much in users'
faces, while still fixing the cases we need to fix.
Per bug #17486 from Nicolas Lutic. This issue is ancient, so
back-patch to all supported branches.
Discussion: https://postgr.es/m/17486-1ad6fd786728b8af@postgresql.org
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/matview.out
doc: Mention pg_read_all_stats in description of track_activities
commit : bb60f25755d43e039913464c1e0bb38aab1d317f
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 21 May 2022 19:06:01 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 21 May 2022 19:06:01 +0900
The description of track_activities mentioned that it is visible to
superusers and that the information related to the current session can
be seen, without telling about pg_read_all_stats. Roles that are
granted the privileges of pg_read_all_stats can also see this
information, so mention it in the docs.
Author: Ian Barwick
Reviewed-by: Nathan Bossart
Discussion: https://postgr.es/m/CAB8KJ=jhPyYFu-A5r-ZGP+Ax715mUKsMxAGcEQ9Cx_mBAmrPow@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/config.sgml
Fix DDL deparse of CREATE OPERATOR CLASS
commit : 3753a169e110bfedd1c7eef5159d3a5c05cd881e
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 20 May 2022 18:52:55 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 20 May 2022 18:52:55 +0200
When an implicit operator family is created, it wasn't getting reported.
Make it do so.
This has always been missing. Backpatch to 10.
Author: Masahiko Sawada <sawada.mshk@gmail.com>
Reported-by: Leslie LEMAIRE <leslie.lemaire@developpement-durable.gouv.fr>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Reviewed-by: Michael Paquiër <michael@paquier.xyz>
Discussion: https://postgr.es/m/f74d69e151b22171e8829551b1159e77@developpement-durable.gouv.fr
M src/backend/commands/opclasscmds.c
M src/backend/tcop/utility.c
M src/test/modules/test_ddl_deparse/expected/opfamily.out
M src/test/regress/expected/event_trigger.out
M src/test/regress/sql/event_trigger.sql
Backpatch regression tests added by 2d689babe3cb
commit : 99867e7277229bb234f369a14f100148171d2276
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 20 May 2022 17:52:16 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 20 May 2022 17:52:16 +0200
A new plpgsql test function was added in 14 and up to cover for a bugfix
that was not backpatchable. We can add it to older versions as a way to
cover other bits of DDL event triggers, with an exception clause to
avoid the problematic corner case.
Originally authored by Michaël Paquier.
Backpatch: 10 through 13.
Discussion: https://postgr.es/m/202205201523.7m5jbfvyanmj@alvherre.pgsql
M src/test/regress/expected/event_trigger.out
M src/test/regress/sql/event_trigger.sql
Doc: clarify location of libpq's default service file on Windows.
commit : 227c180efe125d6eeba34ab82539e71614f2d13d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 May 2022 18:36:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 May 2022 18:36:07 -0400
The documentation didn't specify the name of the per-user service file
on Windows, and extrapolating from the pattern used for other config
files gave the wrong answer. The fact that it isn't consistent with the
others sure seems like a bug, but it's far too late to change that now;
we'd just penalize people who worked it out in the past. So, simply
document the true state of affairs.
In passing, fix some gratuitous differences between the discussions
of the service file and the password file.
Julien Rouhaud, per question from Dominique Devienne.
Backpatch to all supported branches. I (tgl) also chose to back-patch
the part of commit ba356a397 that touched libpq.sgml's description of
the service file --- in hindsight, I'm not sure why I didn't do so at
the time, as it includes some fairly essential information.
Discussion: https://postgr.es/m/CAFCRh-_mdLrh8eYVzhRzu4c8bAFEBn=rwoHOmFJcQOTsCy5nig@mail.gmail.com
M doc/src/sgml/libpq.sgml
Repurpose PROC_COPYABLE_FLAGS as PROC_XMIN_FLAGS
commit : 5fd0cccc116b248be615f5a7cd35b5d46c0589d1
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 19 May 2022 16:20:32 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 19 May 2022 16:20:32 +0200
This is a slight, convenient semantics change from what commit
0f0cfb494004 ("Fix parallel operations that prevent oldest xmin from
advancing") introduced that lets us simplify the coding in the one place
where it is used.
Backpatch to 13. This is related to commit 6fea65508a1a ("Tighten
ComputeXidHorizons' handling of walsenders") rewriting the code site
where this is used, which has not yet been backpatched, but it may well
be in the future.
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>
Discussion: https://postgr.es/m/202204191637.eldwa2exvguw@alvherre.pgsql
M src/backend/storage/ipc/procarray.c
M src/include/storage/proc.h
Update xml_1.out and xml_2.out
commit : 5139db55636bc39c06232ada1b195f7d5d6950e0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 May 2022 23:19:53 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 May 2022 23:19:53 +0200
Commit 0fbf01120023 should have updated them but didn't.
M src/test/regress/expected/xml_1.out
M src/test/regress/expected/xml_2.out
Check column list length in XMLTABLE/JSON_TABLE alias
commit : 80656f00f85668bb828c1eb878876e5bedcbf4c4
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 May 2022 20:28:31 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 May 2022 20:28:31 +0200
We weren't checking the length of the column list in the alias clause of
an XMLTABLE or JSON_TABLE function (a "tablefunc" RTE), and it was
possible to make the server crash by passing an overly long one. Fix it
by throwing an error in that case, like the other places that deal with
alias lists.
In passing, modify the equivalent test used for join RTEs to look like
the other ones, which was different for no apparent reason.
This bug came in when XMLTABLE was born in version 10; backpatch to all
stable versions.
Reported-by: Wang Ke <krking@zju.edu.cn>
Discussion: https://postgr.es/m/17480-1c9d73565bb28e90@postgresql.org
M src/backend/parser/parse_clause.c
M src/backend/parser/parse_relation.c
M src/test/regress/expected/int2.out
M src/test/regress/expected/join.out
M src/test/regress/expected/with.out
M src/test/regress/expected/xml.out
M src/test/regress/sql/int2.sql
M src/test/regress/sql/join.sql
M src/test/regress/sql/with.sql
M src/test/regress/sql/xml.sql
Fix control file update done in restartpoints still running after promotion
commit : 2e9559b30239ce3cf69383ced208a72a7eb99335
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 16 May 2022 11:26:26 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 16 May 2022 11:26:26 +0900
If a cluster is promoted (aka the control file shows a state different
than DB_IN_ARCHIVE_RECOVERY) while CreateRestartPoint() is still
processing, this function could miss an update of the control file for
"checkPoint" and "checkPointCopy" but still do the recycling and/or
removal of the past WAL segments, assuming that the to-be-updated LSN
values should be used as reference points for the cleanup. This causes
a follow-up restart attempting crash recovery to fail with a PANIC on a
missing checkpoint record if the end-of-recovery checkpoint triggered by
the promotion did not complete while the cluster abruptly stopped or
crashed before the completion of this checkpoint. The PANIC would be
caused by the redo LSN referred in the control file as located in a
segment already gone, recycled by the previous restartpoint with
"checkPoint" out-of-sync in the control file.
This commit fixes the update of the control file during restartpoints so
as "checkPoint" and "checkPointCopy" are updated even if the cluster has
been promoted while a restartpoint is running, to be on par with the set
of WAL segments actually recycled in the end of CreateRestartPoint().
7863ee4 has fixed this problem already on master, but the release timing
of the latest point versions did not let me enough time to study and fix
that on all the stable branches.
Reported-by: Fujii Masao, Rui Zhao
Author: Kyotaro Horiguchi
Reviewed-by: Nathan Bossart, Michael Paquier
Discussion: https://postgr.es/m/20220316.102444.2193181487576617583.horikyota.ntt@gmail.com
Backpatch-through: 10
M src/backend/access/transam/xlog.c
Make pull_var_clause() handle GroupingFuncs exactly like Aggrefs.
commit : b7579b25c8159bfda7b70c9ec005aae243017563
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 May 2022 11:31:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 May 2022 11:31:46 -0400
This follows in the footsteps of commit 2591ee8ec by removing one more
ill-advised shortcut from planning of GroupingFuncs. It's true that
we don't intend to execute the argument expression(s) at runtime, but
we still have to process any Vars appearing within them, or we risk
failure at setrefs.c time (or more fundamentally, in EXPLAIN trying
to print such an expression). Vars in upper plan nodes have to have
referents in the next plan level, whether we ever execute 'em or not.
Per bug #17479 from Michael J. Sullivan. Back-patch to all supported
branches.
Richard Guo
Discussion: https://postgr.es/m/17479-6260deceaf0ad304@postgresql.org
M src/backend/optimizer/util/var.c
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/groupingsets.sql
Fix the logical replication timeout during large transactions.
commit : 55558df2374167af38534df988ec3b9d0b0019f0
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 11 May 2022 10:41:24 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 11 May 2022 10:41:24 +0530
The problem is that we don't send keep-alive messages for a long time
while processing large transactions during logical replication where we
don't send any data of such transactions. This can happen when the table
modified in the transaction is not published or because all the changes
got filtered. We do try to send the keep_alive if necessary at the end of
the transaction (via WalSndWriteData()) but by that time the
subscriber-side can timeout and exit.
To fix this we try to send the keepalive message if required after
processing certain threshold of changes.
Reported-by: Fabrice Chapuis
Author: Wang wei and Amit Kapila
Reviewed By: Masahiko Sawada, Euler Taveira, Hou Zhijie, Hayato Kuroda
Backpatch-through: 10
Discussion: https://postgr.es/m/CAA5-nLARN7-3SLU_QUxfy510pmrYK6JJb=bk3hcgemAM_pAv+w@mail.gmail.com
M src/backend/replication/logical/logical.c
M src/backend/replication/pgoutput/pgoutput.c
M src/backend/replication/walsender.c
M src/include/replication/logical.h
Improve setup of environment values for commands in MSVC's vcregress.pl
commit : b9d70ef34b833fd63e3ff9f049dbbcdfda9dc9fe
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 11 May 2022 10:22:34 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 11 May 2022 10:22:34 +0900
The current setup assumes that commands for lz4, zstd and gzip always
exist by default if not enforced by a user's environment. However,
vcpkg, as one example, installs libraries but no binaries, so this
default setup to assume that a command should always be present would
cause failures. This commit improves the detection of such external
commands as follows:
* If a ENV value is available, trust the environment/user and use it.
* If a ENV value is not available, check its execution by looking in the
current PATH, by launching a simple "$command --version" (that should be
portable enough).
** On execution failure, ignore ENV{command}.
** On execution success, set ENV{command} = "$command".
Note that this new rule applies to gzip, lz4 and zstd but not tar that
we assume will always exist. Those commands are set up in the
environment only when using bincheck and taptest. The CI includes all
those commands and I have checked that their setup is correct there. I
have also tested this change in a MSVC environment where we have none of
those commands.
While on it, remove the references to lz4 from the documentation and
vcregress.pl in ~v13. --with-lz4 has been added in v14~ so there is no
point to have this information in these older branches.
Reported-by: Andrew Dunstan
Reviewed-by: Andrew Dunstan
Discussion: https://postgr.es/m/14402151-376b-a57a-6d0c-10ad12608e12@dunslane.net
Backpatch-through: 10
M doc/src/sgml/install-windows.sgml
M src/tools/msvc/vcregress.pl
configure: don't probe for libldap_r if libldap is 2.5 or newer.
commit : af9b967671533965debc9caf3e20fd65a3c71ae4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 May 2022 18:42:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 May 2022 18:42:02 -0400
In OpenLDAP 2.5 and later, libldap itself is always thread-safe and
there's never a libldap_r. Our existing coding dealt with that
by assuming it wouldn't find libldap_r if libldap is thread-safe.
But that rule fails to cope if there are multiple OpenLDAP versions
visible, as is likely to be the case on macOS in particular. We'd
end up using shiny new libldap in the backend and a hoary libldap_r
in libpq.
Instead, once we've found libldap, check if it's >= 2.5 (by
probing for a function introduced then) and don't bother looking
for libldap_r if so. While one can imagine library setups that
this'd still give the wrong answer for, they seem unlikely to
occur in practice.
Per report from Peter Eisentraut. Back-patch to all supported branches.
Discussion: https://postgr.es/m/fedacd7c-2a38-25c9-e7ff-dea549d0e979@enterprisedb.com
M configure
M configure.in
Stamp 13.7.
commit : 4695fdb40fbb1e977e7e62f7d9af1fa948230d6a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 17:16:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 17:16:30 -0400
M configure
M configure.in
Last-minute updates for release notes.
commit : 0c8215c7b6bdf528edab88943438f0db9afad49b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 14:29:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 14:29:53 -0400
Security: CVE-2022-1552
M doc/src/sgml/release-13.sgml
Fix core dump in transformValuesClause when there are no columns.
commit : 91a3a74c65f4094420b28c393ac1d38af8ae4c4a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 14:15:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 14:15:37 -0400
The parser code that transformed VALUES from row-oriented to
column-oriented lists failed if there were zero columns.
You can't write that straightforwardly (though probably you
should be able to), but the case can be reached by expanding
a "tab.*" reference to a zero-column table.
Per bug #17477 from Wang Ke. Back-patch to all supported branches.
Discussion: https://postgr.es/m/17477-0af3c6ac6b0a6ae0@postgresql.org
M src/backend/parser/analyze.c
M src/test/regress/expected/select.out
M src/test/regress/sql/select.sql
Revert "Disallow infinite endpoints in generate_series() for timestamps."
commit : 7f0754bc4c0a0abadcbe02e886e31305c37a7053
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 11:02:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 11:02:37 -0400
This reverts commit eafdf9de06e9b60168f5e47cedcfceecdc6d4b5f
and its back-branch counterparts. Corey Huinker pointed out that
we'd discussed this exact change back in 2016 and rejected it,
on the grounds that there's at least one usage pattern with LIMIT
where an infinite endpoint can usefully be used. Perhaps that
argument needs to be re-litigated, but there's no time left before
our back-branch releases. To keep our options open, restore the
status quo ante; if we do end up deciding to change things, waiting
one more quarter won't hurt anything.
Rather than just doing a straight revert, I added a new test case
demonstrating the usage with LIMIT. That'll at least remind us of
the issue if we forget again.
Discussion: https://postgr.es/m/3603504.1652068977@sss.pgh.pa.us
Discussion: https://postgr.es/m/CADkLM=dzw0Pvdqp5yWKxMd+VmNkAMhG=4ku7GnCZxebWnzmz3Q@mail.gmail.com
M src/backend/utils/adt/timestamp.c
M src/test/regress/expected/timestamp.out
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamp.sql
M src/test/regress/sql/timestamptz.sql
In REFRESH MATERIALIZED VIEW, set user ID before running user code.
commit : 88743d581e1bdedc13e4ca33c5a6597a5d2dbdc4
author : Noah Misch <noah@leadboat.com>
date : Mon, 9 May 2022 08:35:08 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 9 May 2022 08:35:08 -0700
It intended to, but did not, achieve this. Adopt the new standard of
setting user ID just after locking the relation. Back-patch to v10 (all
supported versions).
Reviewed by Simon Riggs. Reported by Alvaro Herrera.
Security: CVE-2022-1552
M src/backend/commands/matview.c
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql
Make relation-enumerating operations be security-restricted operations.
commit : 35edcc0cee7bf7d4746e3e5b7966b1f0ec509560
author : Noah Misch <noah@leadboat.com>
date : Mon, 9 May 2022 08:35:08 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 9 May 2022 08:35:08 -0700
When a feature enumerates relations and runs functions associated with
all found relations, the feature's user shall not need to trust every
user having permission to create objects. BRIN-specific functionality
in autovacuum neglected to account for this, as did pg_amcheck and
CLUSTER. An attacker having permission to create non-temp objects in at
least one schema could execute arbitrary SQL functions under the
identity of the bootstrap superuser. CREATE INDEX (not a
relation-enumerating operation) and REINDEX protected themselves too
late. This change extends to the non-enumerating amcheck interface.
Back-patch to v10 (all supported versions).
Sergey Shinderuk, reviewed (in earlier versions) by Alexander Lakhin.
Reported by Alexander Lakhin.
Security: CVE-2022-1552
M contrib/amcheck/expected/check_btree.out
M contrib/amcheck/sql/check_btree.sql
M contrib/amcheck/verify_nbtree.c
M src/backend/access/brin/brin.c
M src/backend/catalog/index.c
M src/backend/commands/cluster.c
M src/backend/commands/indexcmds.c
M src/backend/utils/init/miscinit.c
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql
Translation updates
commit : 916463773c9b873c3537a735bd09183bb8488d0f
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 May 2022 12:27:22 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 May 2022 12:27:22 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 7c8dcb6669ccc6ae33090d02ed92f0bad6ada742
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/initdb/po/ru.po
M src/bin/initdb/po/sv.po
M src/bin/pg_archivecleanup/po/sv.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_checksums/po/sv.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_config/po/sv.po
M src/bin/pg_controldata/po/sv.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_ctl/po/sv.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_resetwal/po/sv.po
M src/bin/pg_rewind/po/de.po
M src/bin/pg_rewind/po/fr.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/po/sv.po
M src/bin/pg_test_timing/po/sv.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_verifybackup/po/sv.po
M src/bin/pg_waldump/po/ru.po
M src/bin/pg_waldump/po/sv.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
M src/bin/scripts/po/ru.po
M src/bin/scripts/po/sv.po
M src/interfaces/ecpg/ecpglib/po/sv.po
M src/interfaces/ecpg/preproc/po/sv.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/ru.po
M src/interfaces/libpq/po/sv.po
M src/pl/plperl/po/ru.po
M src/pl/plperl/po/sv.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpython/po/sv.po
M src/pl/tcl/po/sv.po
Disable 031_recovery_conflict.pl until after minor releases.
commit : 6348e46850681daf1e648fd11cafabbe4aba8597
author : Andres Freund <andres@anarazel.de>
date : Sun, 8 May 2022 17:59:30 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 8 May 2022 17:59:30 -0700
f40d362a667 disabled part of 031_recovery_conflict.pl due to instability
that's not trivial to fix in the back branches. That fixed most of the
issues. But there was one more failure (on lapwing / REL_10_STABLE).
That failure looks like it might be caused by a genuine problem. Disable the
test until after the set of releases, to avoid packagers etc potentially
having to fight with a test failure they can't do anything about.
Discussion: https://postgr.es/m/3447060.1652032749@sss.pgh.pa.us
Backpatch: 10-14
M src/test/recovery/t/031_recovery_conflict.pl
Release notes for 14.3, 13.7, 12.11, 11.16, 10.21.
commit : fdaaba15397a71786a8ddcd987e067ab94e2b45c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 May 2022 12:36:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 May 2022 12:36:38 -0400
M doc/src/sgml/release-13.sgml
Fix back-patch of "Under has_wal_read_bug, skip .../001_wal.pl."
commit : 4caa85e4f358c8c442fd5855fbc2d80237d3e857
author : Noah Misch <noah@leadboat.com>
date : Sat, 7 May 2022 09:12:56 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 7 May 2022 09:12:56 -0700
Per buildfarm members tadarida, snapper, and kittiwake. Back-patch to
v10 (all supported versions).
M contrib/bloom/t/001_wal.pl
Under has_wal_read_bug, skip contrib/bloom/t/001_wal.pl.
commit : 23213f53ba206f8104ccbac9934190fdbfbfc082
author : Noah Misch <noah@leadboat.com>
date : Sat, 7 May 2022 00:33:15 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 7 May 2022 00:33:15 -0700
Per buildfarm members snapper and kittiwake. Back-patch to v10 (all
supported versions).
Discussion: https://postgr.es/m/20220116210241.GC756210@rfd.leadboat.com
M contrib/bloom/t/001_wal.pl
Temporarily skip recovery deadlock test in back branches.
commit : 4e39957e6eb52887c2d631e9edf08a07c306ec9f
author : Andres Freund <andres@anarazel.de>
date : Fri, 6 May 2022 09:01:08 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 6 May 2022 09:01:08 -0700
The recovery deadlock test has a timing issue that was fixed in 5136967f1eb in
HEAD. Unfortunately the same fix doesn't quite work in the back branches: 1)
adjust_conf() doesn't exist, which is easy enough to work around 2) a restart
cleares the recovery conflict stats < 15.
These issues can be worked around, but given the upcoming set of minor
releases, skip the problematic test for now. The buildfarm doesn't show
failures in other parts of 031_recovery_conflict.pl.
Discussion: https://postgr.es/m/20220506155827.dfnaheq6ufylwrqf@alap3.anarazel.de
Backpatch: 10-14
M src/test/recovery/t/031_recovery_conflict.pl
Backpatch addition of pump_until() more completely.
commit : 6ab90d215afcec4c8d6583cb359ee0c1c1530a20
author : Andres Freund <andres@anarazel.de>
date : Fri, 6 May 2022 08:39:07 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 6 May 2022 08:39:07 -0700
In a2ab9c06ea1 I just backpatched the introduction of pump_until(), without
changing the existing local definitions (as 6da65a3f9a9). The necessary
changes seemed more verbose than desirable. However, that leads to warnings,
as I failed to realize...
Backpatch to all versions containing pump_until() calls before
f74496dd611 (there's none in 10).
Discussion: https://postgr.es/m/2808491.1651802860@sss.pgh.pa.us
Discussion: https://postgr.es/m/18b37361-b482-b9d8-f30d-6115cd5ce25c@enterprisedb.com
Backpatch: 11-14
M src/test/recovery/t/013_crash_restart.pl
Update time zone data files to tzdata release 2022a.
commit : e9735d1af176e73158931a14b5f304a42f94f7d6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 May 2022 14:54:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 May 2022 14:54:53 -0400
DST law changes in Palestine. Historical corrections for
Chile and Ukraine.
M src/timezone/data/tzdata.zi
Revert "Fix timing issue in deadlock recovery conflict test."
commit : 27e97d0747ad0b615fd05b468bf09b12de196e44
author : Andres Freund <andres@anarazel.de>
date : Wed, 4 May 2022 14:16:41 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 4 May 2022 14:16:41 -0700
This reverts commit 8a3a8d9f103e360fffc02089810a520e22521ae2.
M src/test/recovery/t/031_recovery_conflict.pl
Fix timing issue in deadlock recovery conflict test.
commit : 8a3a8d9f103e360fffc02089810a520e22521ae2
author : Andres Freund <andres@anarazel.de>
date : Wed, 4 May 2022 12:50:38 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 4 May 2022 12:50:38 -0700
Per buildfarm members longfin and skink.
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de
Backpatch: 10-
M src/test/recovery/t/031_recovery_conflict.pl
Backpatch 031_recovery_conflict.pl.
commit : 0446d3bf3909247f06de9b8f08a739caf7cc72ca
author : Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:29:35 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:29:35 -0700
The prior commit showed that the introduction of recovery conflict tests was a
good idea. Without these tests it's hard to know that the fix didn't break
something...
031_recovery_conflict.pl was introduced in 9f8a050f68d and extended in
21e184403bf.
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de
Backpatch: 10-14
A src/test/recovery/t/031_recovery_conflict.pl
Fix possibility of self-deadlock in ResolveRecoveryConflictWithBufferPin().
commit : 57c5ad168be1ce9a5e91adb4c576996921cd8627
author : Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:25:00 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:25:00 -0700
The tests added in 9f8a050f68d failed nearly reliably on FreeBSD in CI, and
occasionally on the buildfarm. That turns out to be caused not by a bug in the
test, but by a longstanding bug in recovery conflict handling.
The standby timeout handler, used by ResolveRecoveryConflictWithBufferPin(),
executed SendRecoveryConflictWithBufferPin() inside a signal handler. A bad
idea, because the deadlock timeout handler (or a spurious latch set) could
have interrupted ProcWaitForSignal(). If unlucky that could cause a
self-deadlock on ProcArrayLock, if the deadlock check is in
SendRecoveryConflictWithBufferPin()->CancelDBBackends().
To fix, set a flag in StandbyTimeoutHandler(), and check the flag in
ResolveRecoveryConflictWithBufferPin().
Subsequently the recovery conflict tests will be backpatched.
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de
Backpatch: 10-
M src/backend/storage/ipc/standby.c
Backpatch addition of wait_for_log(), pump_until().
commit : 90abe1e17f9d3f725cf92a3ef43593ec56eaf671
author : Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:09:43 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:09:43 -0700
These were originally introduced in a2ab9c06ea1 and a2ab9c06ea1, as they are
needed by a about-to-be-backpatched test.
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de
Backpatch: 10-14
M src/test/perl/PostgreSQL/Test/Utils.pm
M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
Fix typo in comment.
commit : d85f2bfa09f64e52436e8f05a9e112e160bace65
author : Etsuro Fujita <efujita@postgresql.org>
date : Mon, 2 May 2022 16:45:04 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Mon, 2 May 2022 16:45:04 +0900
M src/backend/storage/ipc/latch.c
Inhibit mingw CRT's auto-globbing of command line arguments
commit : d9cede2c3bfd0739acf294e4e83b36ea9de36b83
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 25 Apr 2022 15:02:13 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 25 Apr 2022 15:02:13 -0400
For some reason by default the mingw C Runtime takes it upon itself to
expand program arguments that look like shell globbing characters. That
has caused much scratching of heads and mis-attribution of the causes of
some TAP test failures, so stop doing that.
This removes an inconsistency with Windows binaries built with MSVC,
which have no such behaviour.
Per suggestion from Noah Misch.
Backpatch to all live branches.
Discussion: https://postgr.es/m/20220423025927.GA1274057@rfd.leadboat.com
M src/common/exec.c
Remove inadequate assertion check in CTE inlining.
commit : e6440d5007aaa33f946ab63f2c1dfd1ee99e2050
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2022 17:58:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2022 17:58:52 -0400
inline_cte() expected to find exactly as many references to the
target CTE as its cterefcount indicates. While that should be
accurate for the tree as emitted by the parser, there are some
optimizations that occur upstream of here that could falsify it,
notably removal of unused subquery output expressions.
Trying to make the accounting 100% accurate seems expensive and
doomed to future breakage. It's not really worth it, because
all this code is protecting is downstream assumptions that every
referenced CTE has a plan. Let's convert those assertions to
regular test-and-elog just in case there's some actual problem,
and then drop the failing assertion.
Per report from Tomas Vondra (thanks also to Richard Guo for
analysis). Back-patch to v12 where the faulty code came in.
Discussion: https://postgr.es/m/29196a1e-ed47-c7ca-9be2-b1c636816183@enterprisedb.com
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/subselect.c
M src/include/nodes/pathnodes.h
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql
Support new perl module namespace in stable branches
commit : 1c60a99dd9a2064125d503227d8f8b17d33dc4ed
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 21 Apr 2022 09:20:00 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 21 Apr 2022 09:20:00 -0400
Commit b3b4d8e68a moved our perl test modules to a better namespace
structure, but this has made life hard for people wishing to backpatch
improvements in the TAP tests. Here we alleviate much of that difficulty
by implementing the new module names on top of the old modules, mostly
by using a little perl typeglob aliasing magic, so that we don't have a
dual maintenance burden. This should work both for the case where a new
test is backpatched and the case where a fix to an existing test that
uses the new namespace is backpatched.
Reviewed by Michael Paquier
Per complaint from Andres Freund
Discussion: https://postgr.es/m/20220418141530.nfxtkohefvwnzncl@alap3.anarazel.de
Applied to branches 10 through 14
A src/test/perl/PostgreSQL/Test/Cluster.pm
A src/test/perl/PostgreSQL/Test/Utils.pm
M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
Fix CLUSTER tuplesorts on abbreviated expressions.
commit : 1272630a249798a0fce6a00383c78f8129434523
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Apr 2022 17:17:39 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Apr 2022 17:17:39 -0700
CLUSTER sort won't use the datum1 SortTuple field when clustering
against an index whose leading key is an expression. This makes it
unsafe to use the abbreviated keys optimization, which was missed by the
logic that sets up SortSupport state. Affected tuplesorts output tuples
in a completely bogus order as a result (the wrong SortSupport based
comparator was used for the leading attribute).
This issue is similar to the bug fixed on the master branch by recent
commit cc58eecc5d. But it's a far older issue, that dates back to the
introduction of the abbreviated keys optimization by commit 4ea51cdfe8.
Backpatch to all supported versions.
Author: Peter Geoghegan <pg@bowt.ie>
Author: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/CA+hUKG+bA+bmwD36_oDxAoLrCwZjVtST2fqe=b4=qZcmU7u89A@mail.gmail.com
Backpatch: 10-
M src/backend/utils/sort/tuplesort.c
M src/test/regress/expected/cluster.out
M src/test/regress/sql/cluster.sql
Disallow infinite endpoints in generate_series() for timestamps.
commit : 8275ba773dfe3168115bb3d32728111d9c4becb6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2022 18:08:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2022 18:08:15 -0400
Such cases will lead to infinite loops, so they're of no practical
value. The numeric variant of generate_series() already threw error
for this, so borrow its message wording.
Per report from Richard Wesley. Back-patch to all supported branches.
Discussion: https://postgr.es/m/91B44E7B-68D5-448F-95C8-B4B3B0F5DEAF@duckdblabs.com
M src/backend/utils/adt/timestamp.c
M src/test/regress/expected/timestamp.out
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamp.sql
M src/test/regress/sql/timestamptz.sql
Fix breakage in AlterFunction().
commit : f583633bc130e8a572e5d29b9c8b2cc48885ecbf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Apr 2022 23:03:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Apr 2022 23:03:59 -0400
An ALTER FUNCTION command that tried to update both the function's
proparallel property and its proconfig list failed to do the former,
because it stored the new proparallel value into a tuple that was
no longer the interesting one. Carelessness in 7aea8e4f2.
(I did not bother with a regression test, because the only likely
future breakage would be for someone to ignore the comment I added
and add some other field update after the heap_modify_tuple step.
A test using existing function properties could not catch that.)
Per report from Bryn Llewellyn. Back-patch to all supported branches.
Discussion: https://postgr.es/m/8AC9A37F-99BD-446F-A2F7-B89AD0022774@yugabyte.com
M src/backend/commands/functioncmds.c
Fix the check to limit sync workers.
commit : 82d4a17a17508a4e6ff9038d81a7dfb9f19e104a
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 19 Apr 2022 09:08:05 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 19 Apr 2022 09:08:05 +0530
We don't allow to invoke more sync workers once we have reached the sync
worker limit per subscription. But the check to enforce this also doesn't
allow to launch an apply worker if it gets restarted.
This code was introduced by commit de43897122 but we caught the problem
only with the test added by recent commit c91f71b9dc which started failing
occasionally in the buildfarm.
As per buildfarm.
Diagnosed-by: Amit Kapila, Masahiko Sawada, Tomas Vondra
Author: Amit Kapila
Backpatch-through: 10
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
https://postgr.es/m/f90d2b03-4462-ce95-a524-d91464e797c8@enterprisedb.com
M src/backend/replication/logical/launcher.c
Avoid invalid array reference in transformAlterTableStmt().
commit : 69cefb3fb8377992bd2ad0dce1b33570b3e5244a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Apr 2022 12:16:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Apr 2022 12:16:45 -0400
Don't try to look at the attidentity field of system attributes,
because they're not there in the TupleDescAttr array. Sometimes
this is harmless because we accidentally pick up a zero, but
otherwise we'll report "no owned sequence found" from an attempt
to alter a system attribute. (It seems possible that a SIGSEGV
could occur, too, though I've not seen it in testing.)
It's not in this function's charter to complain that you can't
alter a system column, so instead just hard-wire an assumption
that system attributes aren't identities. I didn't bother with
a regression test because the appearance of the bug is very
erratic.
Per bug #17465 from Roman Zharkov. Back-patch to all supported
branches. (There's not actually a live bug before v12, because
before that get_attidentity() did the right thing anyway.
But for consistency I changed the test in the older branches too.)
Discussion: https://postgr.es/m/17465-f2a554a6cb5740d3@postgresql.org
M src/backend/parser/parse_utilcmd.c
Fix race in TAP test 002_archiving.pl when restoring history file
commit : a6fc64b9a85e279c5a284c21374edeb857df5252
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Apr 2022 11:40:18 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Apr 2022 11:40:18 +0900
This test, introduced in df86e52, uses a second standby to check that
it is able to remove correctly RECOVERYHISTORY and RECOVERYXLOG at the
end of recovery. This standby uses the archives of the primary to
restore its contents, with some of the archive's contents coming from
the first standby previously promoted. In slow environments, it was
possible that the test did not check what it should, as the history file
generated by the promotion of the first standby may not be stored yet on
the archives the second standby feeds on. So, it could be possible that
the second standby selects an incorrect timeline, without restoring a
history file at all.
This commits adds a wait phase to make sure that the history file
required by the second standby is archived before this cluster is
created. This relies on poll_query_until() with pg_stat_file() and an
absolute path, something not supported in REL_10_STABLE.
While on it, this adds a new test to check that the history file has
been restored by looking at the logs of the second standby. This
ensures that a RECOVERYHISTORY, whose removal needs to be checked,
is created in the first place. This should make the test more robust.
This test has been introduced by df86e52, but it came in light as an
effect of the bug fixed by acf1dd42, where the extra restore_command
calls made the test much slower.
Reported-by: Andres Freund
Discussion: https://postgr.es/m/YlT23IvsXkGuLzFi@paquier.xyz
Backpatch-through: 11
M src/test/recovery/t/002_archiving.pl
Add a temp-install prerequisite to src/interfaces/ecpg "checktcp".
commit : b404513de8579ce29ccb7becbb6e83587352263f
author : Noah Misch <noah@leadboat.com>
date : Sat, 16 Apr 2022 17:43:54 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 16 Apr 2022 17:43:54 -0700
The target failed, tested $PATH binaries, or tested a stale temporary
installation. Commit c66b438db62748000700c9b90b585e756dd54141 missed
this. Back-patch to v10 (all supported versions).
M src/interfaces/ecpg/Makefile
Rethink the delay-checkpoint-end mechanism in the back-branches.
commit : d18c913b786c5ea82f7372c88cf2055050e5176a
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 14 Apr 2022 11:10:11 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 14 Apr 2022 11:10:11 -0400
The back-patch of commit bbace5697df12398e87ffd9879171c39d27f5b33 had
the unfortunate effect of changing the layout of PGPROC in the
back-branches, which could break extensions. This happened because it
changed the delayChkpt from type bool to type int. So, change it back,
and add a new bool delayChkptEnd field instead. The new field should
fall within what used to be padding space within the struct, and so
hopefully won't cause any extensions to break.
Per report from Markus Wanner and discussion with Tom Lane and others.
Patch originally by me, somewhat revised by Markus Wanner per a
suggestion from Michael Paquier. A very similar patch was developed
by Kyotaro Horiguchi, but I failed to see the email in which that was
posted before writing one of my own.
Discussion: http://postgr.es/m/CA+Tgmoao-kUD9c5nG5sub3F7tbo39+cdr8jKaOVEs_1aBWcJ3Q@mail.gmail.com
Discussion: http://postgr.es/m/20220406.164521.17171257901083417.horikyota.ntt@gmail.com
M src/backend/access/transam/multixact.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xloginsert.c
M src/backend/catalog/storage.c
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/ipc/procarray.c
M src/include/storage/proc.h
M src/include/storage/procarray.h
pageinspect: Fix handling of all-zero pages
commit : 2275d044d0849251c5e0fa10ee16c73124731f5c
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 14 Apr 2022 15:09:36 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 14 Apr 2022 15:09:36 +0900
Getting from get_raw_page() an all-zero page is considered as a valid
case by the buffer manager and it can happen for example when finding a
corrupted page with zero_damaged_pages enabled (using zero_damaged_pages
to look at corrupted pages happens), or after a crash when a relation
file is extended before any WAL for its new data is generated (before a
vacuum or autovacuum job comes in to do some cleanup).
However, all the functions of pageinspect, as of the index AMs (except
hash that has its own idea of new pages), heap, the FSM or the page
header have never worked with all-zero pages, causing various crashes
when going through the page internals.
This commit changes all the pageinspect functions to be compliant with
all-zero pages, where the choice is made to return NULL or no rows for
SRFs when finding a new page. get_raw_page() still works the same way,
returning a batch of zeros in the bytea of the page retrieved. A hard
error could be used but NULL, while more invasive, is useful when
scanning relation files in full to get a batch of results for a single
relation in one query. Tests are added for all the code paths
impacted.
Reported-by: Daria Lepikhova
Author: Michael Paquier
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
M contrib/pageinspect/brinfuncs.c
M contrib/pageinspect/btreefuncs.c
M contrib/pageinspect/expected/brin.out
M contrib/pageinspect/expected/btree.out
M contrib/pageinspect/expected/gin.out
M contrib/pageinspect/expected/hash.out
M contrib/pageinspect/expected/page.out
M contrib/pageinspect/fsmfuncs.c
M contrib/pageinspect/ginfuncs.c
M contrib/pageinspect/rawpage.c
M contrib/pageinspect/sql/brin.sql
M contrib/pageinspect/sql/btree.sql
M contrib/pageinspect/sql/gin.sql
M contrib/pageinspect/sql/hash.sql
M contrib/pageinspect/sql/page.sql
Prevent access to no-longer-pinned buffer in heapam_tuple_lock().
commit : 44096c31eaf0e9d86053434de8fdce418609c01e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Apr 2022 13:35:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Apr 2022 13:35:02 -0400
heap_fetch() used to have a "keep_buf" parameter that told it to return
ownership of the buffer pin to the caller after finding that the
requested tuple TID exists but is invisible to the specified snapshot.
This was thoughtlessly removed in commit 5db6df0c0, which broke
heapam_tuple_lock() (formerly EvalPlanQualFetch) because that function
needs to do more accesses to the tuple even if it's invisible. The net
effect is that we would continue to touch the page for a microsecond or
two after releasing pin on the buffer. Usually no harm would result;
but if a different session decided to defragment the page concurrently,
we could see garbage data and mistakenly conclude that there's no newer
tuple version to chain up to. (It's hard to say whether this has
happened in the field. The bug was actually found thanks to a later
change that allowed valgrind to detect accesses to non-pinned buffers.)
The most reasonable way to fix this is to reintroduce keep_buf,
although I made it behave slightly differently: buffer ownership
is passed back only if there is a valid tuple at the requested TID.
In HEAD, we can just add the parameter back to heap_fetch().
To avoid an API break in the back branches, introduce an additional
function heap_fetch_extended() in those branches.
In HEAD there is an additional, less obvious API change: tuple->t_data
will be set to NULL in all cases where buffer ownership is not returned,
in particular when the tuple exists but fails the time qual (and
!keep_buf). This is to defend against any other callers attempting to
access non-pinned buffers. We concluded that making that change in back
branches would be more likely to introduce problems than cure any.
In passing, remove a comment about heap_fetch that was obsoleted by
9a8ee1dc6.
Per bug #17462 from Daniil Anisimov. Back-patch to v12 where the bug
was introduced.
Discussion: https://postgr.es/m/17462-9c98a0f00df9bd36@postgresql.org
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/include/access/heapam.h
Docs: adjust pg_upgrade syntax to mark -B as optional
commit : 9144fa27dd7f0ad3a5ef818adb819c5375519115
author : David Rowley <drowley@postgresql.org>
date : Wed, 13 Apr 2022 11:20:06 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 13 Apr 2022 11:20:06 +1200
This was made optional in 959f6d6a1.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com
Backpatch-through: 13, where -B was made optional
M doc/src/sgml/ref/pgupgrade.sgml
Doc: tweak textsearch.sgml for SEO purposes.
commit : 71e0736b6577962874ef3becd09cd74a43ffd92f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Apr 2022 18:21:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Apr 2022 18:21:04 -0400
Google seems to like to return textsearch.html for queries about
GIN and GiST indexes, even though it's not a primary reference
for either. It seems likely that that's because those keywords
appear in the page title. Since "GIN and GiST Index Types" is
not a very apposite title for this material anyway, rename the
section in hopes of stopping that.
Also provide explicit links to the GIN and GiST chapters, to help
anyone who finds their way to this page regardless.
Per gripe from Jan Piotrowski. Back-patch to supported branches.
(Unfortunately Google is likely to continue returning the 9.1
version of this page, but improving that situation is a matter
for the www team.)
Discussion: https://postgr.es/m/164978902252.1276550.9330175733459697101@wrigleys.postgresql.org
M doc/src/sgml/textsearch.sgml
Docs: avoid confusing use of the word "synchronized"
commit : e22fd217ec5b5b454febd5c1a1cc3c3f1c4e3a63
author : David Rowley <drowley@postgresql.org>
date : Wed, 13 Apr 2022 09:17:17 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 13 Apr 2022 09:17:17 +1200
It's misleading to call the data directory the "synchronized data
directory" when discussing a crash scenario when using pg_rewind's
--no-sync option. Here we just remove the word "synchronized" to avoid
any possible confusion.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com
Backpatch-through: 12, where --no-sync was added
M doc/src/sgml/ref/pg_rewind.sgml
Suppress "variable 'pagesaving' set but not used" warning.
commit : 87166d25a4569ac06dc3dcf44fa8c12f0263f836
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 6 Apr 2022 17:03:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 6 Apr 2022 17:03:35 -0400
With asserts disabled, late-model clang notices that this variable
is incremented but never otherwise read.
Discussion: https://postgr.es/m/3171401.1649275153@sss.pgh.pa.us
M src/backend/access/nbtree/nbtdedup.c
Remove obsolete comment
commit : 8f4b5b09096ae5e470c6410312c24581da319733
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 2 Apr 2022 07:27:26 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 2 Apr 2022 07:27:26 +0200
accidentally left behind by 4cb658af70027c3544fb843d77b2e84028762747
M src/include/utils/rel.h
Fix postgres_fdw to check shippability of sort clauses properly.
commit : 79df1d20c59c7fa21326f85be90f875fbe229ec6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 31 Mar 2022 14:29:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 31 Mar 2022 14:29:24 -0400
postgres_fdw would push ORDER BY clauses to the remote side without
verifying that the sort operator is safe to ship. Moreover, it failed
to print a suitable USING clause if the sort operator isn't default
for the sort expression's type. The net result of this is that the
remote sort might not have anywhere near the semantics we expect,
which'd be disastrous for locally-performed merge joins in particular.
We addressed similar issues in the context of ORDER BY within an
aggregate function call in commit 7012b132d, but failed to notice
that query-level ORDER BY was broken. Thus, much of the necessary
logic already existed, but it requires refactoring to be usable
in both cases.
Back-patch to all supported branches. In HEAD only, remove the
core code's copy of find_em_expr_for_rel, which is no longer used
and really should never have been pushed into equivclass.c in the
first place.
Ronan Dunklau, per report from David Rowley;
reviews by David Rowley, Ranier Vilela, and myself
Discussion: https://postgr.es/m/CAApHDvr4OeC2DBVY--zVP83-K=bYrTD7F8SZDhN4g+pj2f2S-A@mail.gmail.com
M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/postgres_fdw.h
M contrib/postgres_fdw/sql/postgres_fdw.sql
Add missing newline in one libpq error message.
commit : fb1d7f4519665f0a6a15a8fd6acc4bb5f86f5697
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 31 Mar 2022 11:24:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 31 Mar 2022 11:24:26 -0400
Oversight in commit a59c79564. Back-patch, as that was.
Noted by Peter Eisentraut.
Discussion: https://postgr.es/m/7f85ef6d-250b-f5ec-9867-89f0b16d019f@enterprisedb.com
M src/interfaces/libpq/fe-secure-openssl.c
doc: Fix typo in ANALYZE documentation
commit : 8421a99ca189120af67df08a6308a0c97ab115ec
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Thu, 31 Mar 2022 12:03:33 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Thu, 31 Mar 2022 12:03:33 +0200
Commit 61fa6ca79b3 accidentally wrote constrast instead of contrast.
Backpatch-through: 10
Discussion: https://postgr.es/m/88903179-5ce2-3d4d-af43-7830372bdcb6@enterprisedb.com
M doc/src/sgml/ref/analyze.sgml
Fix typo in comment.
commit : f042dc6a415decc4e2a9707de5f3fc737e42e1ed
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 30 Mar 2022 19:00:04 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 30 Mar 2022 19:00:04 +0900
M src/backend/commands/copy.c
Revert "Fix replay of create database records on standby"
commit : a54ed2de80ec844e578e26f93ab008c814f56090
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 29 Mar 2022 15:36:21 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 29 Mar 2022 15:36:21 +0200
This reverts commit 49d9cfc68bf4. The approach taken by this patch has
problems, so we'll come up with a radically different fix.
Discussion: https://postgr.es/m/CA+TgmoYcUPL+WOJL2ZzhH=zmrhj0iOQ=iCFM0SuYqBbqZEamEg@mail.gmail.com
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogutils.c
M src/backend/commands/dbcommands.c
M src/backend/commands/tablespace.c
M src/include/access/xlogutils.h
M src/tools/pgindent/typedefs.list
Document autoanalyze limitations for partitioned tables
commit : 78ebfd885be563191d659d7a4ae230e199792e3f
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Mon, 28 Mar 2022 14:27:36 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Mon, 28 Mar 2022 14:27:36 +0200
When dealing with partitioned tables, counters for partitioned tables
are not updated when modifying child tables. This means autoanalyze may
not update optimizer statistics for the parent relations, which can
result in poor plans for some queries.
It's worth documenting this limitation, so that people are aware of it
and can take steps to mitigate it (e.g. by setting up a script executing
ANALYZE regularly).
Backpatch to v10. Older branches are affected too, of couse, but we no
longer maintain those.
Author: Justin Pryzby
Reviewed-by: Zhihong Yu, Tomas Vondra
Backpatch-through: 10
Discussion: https://postgr.es/m/20210913035409.GA10647%40telsasoft.com
M doc/src/sgml/maintenance.sgml
M doc/src/sgml/ref/analyze.sgml
waldump: fix use-after-free in search_directory().
commit : 344d89abf36b9ea559a4b25543bbc7d4206988f5
author : Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 16:38:43 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 16:38:43 -0700
After closedir() dirent->d_name is not valid anymore. As there alerady are a
few places relying on the limited lifetime of pg_waldump, do so here as well,
and just pg_strdup() the string.
The bug was introduced in fc49e24fa69a.
Found by UBSan, run locally.
Backpatch: 11-, like fc49e24fa69 itself.
M src/bin/pg_waldump/pg_waldump.c
Fix breakage of get_ps_display() in the PS_USE_NONE case.
commit : 9016a2a3dc4ee7e41ecda5a8b3a3d3481de94964
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 27 Mar 2022 12:57:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 27 Mar 2022 12:57:46 -0400
Commit 8c6d30f21 caused this function to fail to set *displen
in the PS_USE_NONE code path. If the variable's previous value
had been negative, that'd lead to a memory clobber at some call
sites. We'd managed not to notice due to very thin test coverage
of such configurations, but this appears to explain buildfarm member
lorikeet's recent struggles.
Credit to Andrew Dunstan for spotting the problem. Back-patch
to v13 where the bug was introduced.
Discussion: https://postgr.es/m/136102.1648320427@sss.pgh.pa.us
M src/backend/utils/misc/ps_status.c
pageinspect: Add more sanity checks to prevent out-of-bound reads
commit : 3d4d6dee07777ed2a0f0f7e5938879e07ad02a82
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 27 Mar 2022 17:53:55 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 27 Mar 2022 17:53:55 +0900
A couple of code paths use the special area on the page passed by the
function caller, expecting to find some data in it. However, feeding
an incorrect page can lead to out-of-bound reads when trying to access
the page special area (like a heap page that has no special area,
leading PageGetSpecialPointer() to grab a pointer outside the allocated
page).
The functions used for hash and btree indexes have some protection
already against that, while some other functions using a relation OID
as argument would make sure that the access method involved is correct,
but functions taking in input a raw page without knowing the relation
the page is attached to would run into problems.
This commit improves the set of checks used in the code paths of BRIN,
btree (including one check if a leaf page is found with a non-zero
level), GIN and GiST to verify that the page given in input has a
special area size that fits with each access method, which is done
though PageGetSpecialSize(), becore calling PageGetSpecialPointer().
The scope of the checks done is limited to work with pages that one
would pass after getting a block with get_raw_page(), as it is possible
to craft byteas that could bypass existing code paths. Having too many
checks would also impact the usability of pageinspect, as the existing
code is very useful to look at the content details in a corrupted page,
so the focus is really to avoid out-of-bound reads as this is never a
good thing even with functions whose execution is limited to
superusers.
The safest approach could be to rework the functions so as these fetch a
block using a relation OID and a block number, but there are also cases
where using a raw page is useful.
Tests are added to cover all the code paths that needed such checks, and
an error message for hash indexes is reworded to fit better with what
this commit adds.
Reported-By: Alexander Lakhin
Author: Julien Rouhaud, Michael Paquier
Discussion: https://postgr.es/m/16527-ef7606186f0610a1@postgresql.org
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
M contrib/pageinspect/brinfuncs.c
M contrib/pageinspect/btreefuncs.c
M contrib/pageinspect/expected/brin.out
M contrib/pageinspect/expected/btree.out
M contrib/pageinspect/expected/gin.out
M contrib/pageinspect/expected/hash.out
M contrib/pageinspect/ginfuncs.c
M contrib/pageinspect/hashfuncs.c
M contrib/pageinspect/sql/brin.sql
M contrib/pageinspect/sql/btree.sql
M contrib/pageinspect/sql/gin.sql
M contrib/pageinspect/sql/hash.sql
Suppress compiler warning in relptr_store().
commit : 4fbbea2c1934092581662553fd4be9e84630fc5c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Mar 2022 14:29:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Mar 2022 14:29:29 -0400
clang 13 with -Wextra warns that "performing pointer subtraction with
a null pointer has undefined behavior" in the places where freepage.c
tries to set a relptr variable to constant NULL. This appears to be
a compiler bug, but it's unlikely to get fixed instantly. Fortunately,
we can work around it by introducing an inline support function, which
seems like a good change anyway because it removes the macro's existing
double-evaluation hazard.
Backpatch to v10 where this code was introduced.
Patch by me, based on an idea of Andres Freund's.
Discussion: https://postgr.es/m/48826.1648310694@sss.pgh.pa.us
M src/include/utils/relptr.h
Harden TAP tests that intentionally corrupt page checksums.
commit : 6e9ffcf13a4a0d56f03b4048231066cb5d061299
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Mar 2022 14:23:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Mar 2022 14:23:26 -0400
The previous method for doing that was to write zeroes into a
predetermined set of page locations. However, there's a roughly
1-in-64K chance that the existing checksum will match by chance,
and yesterday several buildfarm animals started to reproducibly
see that, resulting in test failures because no checksum mismatch
was reported.
Since the checksum includes the page LSN, test success depends on
the length of the installation's WAL history, which is affected by
(at least) the initial catalog contents, the set of locales installed
on the system, and the length of the pathname of the test directory.
Sooner or later we were going to hit a chance match, and today is
that day.
Harden these tests by specifically inverting the checksum field and
leaving all else alone, thereby guaranteeing that the checksum is
incorrect.
In passing, fix places that were using seek() to set up for syswrite(),
a combination that the Perl docs very explicitly warn against. We've
probably escaped problems because no regular buffered I/O is done on
these filehandles; but if it ever breaks, we wouldn't deserve or get
much sympathy.
Although we've only seen problems in HEAD, now that we recognize the
environmental dependencies it seems like it might be just a matter
of time until someone manages to hit this in back-branch testing.
Hence, back-patch to v11 where we started doing this kind of test.
Discussion: https://postgr.es/m/3192026.1648185780@sss.pgh.pa.us
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/pg_checksums/t/002_actions.pl
M src/test/perl/PostgresNode.pm
Fix replay of create database records on standby
commit : 50e3ed8e9172fe3cb9bc20899acaa4a8a0fd2388
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 25 Mar 2022 13:16:21 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 25 Mar 2022 13:16:21 +0100
Crash recovery on standby may encounter missing directories when
replaying create database WAL records. Prior to this patch, the standby
would fail to recover in such a case. However, the directories could be
legitimately missing. Consider a sequence of WAL records as follows:
CREATE DATABASE
DROP DATABASE
DROP TABLESPACE
If, after replaying the last WAL record and removing the tablespace
directory, the standby crashes and has to replay the create database
record again, the crash recovery must be able to move on.
This patch adds a mechanism similar to invalid-page tracking, to keep a
tally of missing directories during crash recovery. If all the missing
directory references are matched with corresponding drop records at the
end of crash recovery, the standby can safely continue following the
primary.
Backpatch to 13, at least for now. The bug is older, but fixing it in
older branches requires more careful study of the interactions with
commit e6d8069522c8, which appeared in 13.
A new TAP test file is added to verify the condition. However, because
it depends on commit d6d317dbf615, it can only be added to branch
master. I (Álvaro) manually verified that the code behaves as expected
in branch 14. It's a bit nervous-making to leave the code uncovered by
tests in older branches, but leaving the bug unfixed is even worse.
Also, the main reason this fix took so long is precisely that we
couldn't agree on a good strategy to approach testing for the bug, so
perhaps this is the best we can do.
Diagnosed-by: Paul Guo <paulguo@gmail.com>
Author: Paul Guo <paulguo@gmail.com>
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Author: Asim R Praveen <apraveen@pivotal.io>
Discussion: https://postgr.es/m/CAEET0ZGx9AvioViLf7nbR_8tH9-=27DN5xWJ2P9-ROH16e4JUA@mail.gmail.com
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogutils.c
M src/backend/commands/dbcommands.c
M src/backend/commands/tablespace.c
M src/include/access/xlogutils.h
M src/tools/pgindent/typedefs.list
Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.
commit : 1ce14b6b2fe4af9ac7d7f90eb46c77b2e6deb2de
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 24 Mar 2022 14:36:06 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 24 Mar 2022 14:36:06 -0400
If TRUNCATE causes some buffers to be invalidated and thus the
checkpoint does not flush them, TRUNCATE must also ensure that the
corresponding files are truncated on disk. Otherwise, a replay
from the checkpoint might find that the buffers exist but have
the wrong contents, which may cause replay to fail.
Report by Teja Mupparti. Patch by Kyotaro Horiguchi, per a design
suggestion from Heikki Linnakangas, with some changes to the
comments by me. Review of this and a prior patch that approached
the issue differently by Heikki Linnakangas, Andres Freund, Álvaro
Herrera, Masahiko Sawada, and Tom Lane.
Discussion: http://postgr.es/m/BYAPR06MB6373BF50B469CA393C614257ABF00@BYAPR06MB6373.namprd06.prod.outlook.com
M src/backend/access/transam/multixact.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xloginsert.c
M src/backend/catalog/storage.c
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/ipc/procarray.c
M src/backend/storage/lmgr/proc.c
M src/include/storage/proc.h
M src/include/storage/procarray.h
Don't try to translate NULL in GetConfigOptionByNum().
commit : c0f99bb520da577f34cf7c10e1ea4aab727f08c7
author : Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 13:05:59 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 13:05:59 -0700
Noticed via -fsanitize=undefined. Introduced when a few columns in
GetConfigOptionByNum() / pg_settings started to be translated in 72be8c29a /
PG 12.
Backpatch to all affected branches, for the same reasons as 46ab07ffda9.
Discussion: https://postgr.es/m/20220323173537.ll7klrglnp4gn2um@alap3.anarazel.de
Backpatch: 12-
M src/backend/utils/misc/guc.c
Don't call fwrite() with len == 0 when writing out relcache init file.
commit : 8014c61ebda10d39ef8855b4826aeba5cacd36e1
author : Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 13:05:25 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 13:05:25 -0700
Noticed via -fsanitize=undefined.
Backpatch to all branches, for the same reasons as 46ab07ffda9.
Discussion: https://postgr.es/m/20220323173537.ll7klrglnp4gn2um@alap3.anarazel.de
Backpatch: 10-
M src/backend/utils/cache/relcache.c
configure: check for dlsym instead of dlopen.
commit : 7c163aa93fe6e37f231cef9ac08d5041855228fa
author : Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 12:43:14 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 12:43:14 -0700
When building with sanitizers the sanitizer library provides dlopen, but not
dlsym(), making configure think that -ldl isn't needed. Just checking for
dlsym() ought to suffice, hard to see dlsym() being provided without dlopen()
also being provided.
Backpatch to all branches, for the same reasons as 46ab07ffda9.
Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/20220323173537.ll7klrglnp4gn2um@alap3.anarazel.de
Backpatch: 10-
M configure
M configure.in
pg_upgrade: Upgrade an Assert to a real 'if' test
commit : ca26c64581b529b2191757dbb27b94c6b0c101be
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 23 Mar 2022 19:23:51 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 23 Mar 2022 19:23:51 +0100
It seems possible for the condition being tested to be true in
production, and nobody would never know (except when some data
eventually becomes corrupt?).
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m//202109040001.zky3wgv2qeqg@alvherre.pgsql
M src/bin/pg_rewind/parsexlog.c
Fix "missing continuation record" after standby promotion
commit : 98eb3e06ce3a628adabeb90584c002a3c4bcec8e
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 23 Mar 2022 18:22:10 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 23 Mar 2022 18:22:10 +0100
Invalidate abortedRecPtr and missingContrecPtr after a missing
continuation record is successfully skipped on a standby. This fixes a
PANIC caused when a recently promoted standby attempts to write an
OVERWRITE_RECORD with an LSN of the previously read aborted record.
Backpatch to 10 (all stable versions).
Author: Sami Imseih <simseih@amazon.com>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/44D259DE-7542-49C4-8A52-2AB01534DCA9@amazon.com
M src/backend/access/transam/xlog.c
M src/test/recovery/t/026_overwrite_contrecord.pl
Try to stabilize vacuum test.
commit : f784fcdc44435597c52b41f97bfbdf082a783c82
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 23 Mar 2022 14:31:18 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 23 Mar 2022 14:31:18 +1300
As commits b700f96c and 3414099c did for the reloptions test, make
sure VACUUM can always truncate the table as expected.
Back-patch to 12, where vacuum_truncate arrived.
Discussion: https://postgr.es/m/CAD21AoCNoWjYkdEtr%2BVDoF9v__V905AedKZ9iF%3DArgCtrbxZqw%40mail.gmail.com
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Add missing dependency of pg_dumpall to WIN32RES.
commit : f183e23cc8a9107b6a8ddc7f16b97da926fddf94
author : Andres Freund <andres@anarazel.de>
date : Tue, 22 Mar 2022 08:22:02 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 22 Mar 2022 08:22:02 -0700
When cross-building to windows, or building with mingw on windows, the build
could fail with
x86_64-w64-mingw32-gcc: error: win32ver.o: No such file or director
because pg_dumpall didn't depend on WIN32RES, but it's recipe references
it. The build nevertheless succeeded most of the time, due to
pg_dump/pg_restore having the required dependency, causing win32ver.o to be
built.
Reported-By: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/CA+hUKGJeekpUPWW6yCVdf9=oBAcCp86RrBivo4Y4cwazAzGPng@mail.gmail.com
Backpatch: 10-, omission present on all live branches
M src/bin/pg_dump/Makefile
Fix failures in SSL tests caused by out-of-tree keys and certificates
commit : f32be9938ca48d9658eaf29a30c78f855d36e97a
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 22 Mar 2022 13:21:39 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 22 Mar 2022 13:21:39 +0900
This issue is environment-sensitive, where the SSL tests could fail in
various way by feeding on defaults provided by sslcert, sslkey,
sslrootkey, sslrootcert, sslcrl and sslcrldir coming from a local setup,
as of ~/.postgresql/ by default. Horiguchi-san has reported two
failures, but more advanced testing from me (aka inclusion of garbage
SSL configuration in ~/.postgresql/ for all the configuration
parameters) has showed dozens of failures that can be triggered in the
whole test suite.
History has showed that we are not good when it comes to address such
issues, fixing them locally like in dd87799, and such problems keep
appearing. This commit strengthens the entire test suite to put an end
to this set of problems by embedding invalid default values in all the
connection strings used in the tests. The invalid values are prefixed
in each connection string, relying on the follow-up values passed in the
connection string to enforce any invalid value previously set. Note
that two tests related to CRLs are required to fail with certain pre-set
configurations, but we can rely on enforcing an empty value instead
after the invalid set of values.
Reported-by: Kyotaro Horiguchi
Reviewed-by: Andrew Dunstan, Daniel Gustafsson, Kyotaro Horiguchi
Discussion: https://postgr.es/m/20220316.163658.1122740600489097632.horikyota.ntt@gmail.com
backpatch-through: 10
M src/test/ssl/t/001_ssltests.pl
Fix assorted missing logic for GroupingFunc nodes.
commit : dfefe38fbea4c6f003319a9921f3fd6ded5e70aa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Mar 2022 17:44:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Mar 2022 17:44:29 -0400
The planner needs to treat GroupingFunc like Aggref for many purposes,
in particular with respect to processing of the argument expressions,
which are not to be evaluated at runtime. A few places hadn't gotten
that memo, notably including subselect.c's processing of outer-level
aggregates. This resulted in assertion failures or wrong plans for
cases in which a GROUPING() construct references an outer aggregation
level.
Also fix missing special cases for GroupingFunc in cost_qual_eval
(resulting in wrong cost estimates for GROUPING(), although it's
not clear that that would affect plan shapes in practice) and in
ruleutils.c (resulting in excess parentheses in pretty-print mode).
Per bug #17088 from Yaoguang Chen. Back-patch to all supported
branches.
Richard Guo, Tom Lane
Discussion: https://postgr.es/m/17088-e33882b387de7f5c@postgresql.org
M src/backend/nodes/nodeFuncs.c
M src/backend/optimizer/path/costsize.c
M src/backend/optimizer/plan/subselect.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/groupingsets.sql
Fix risk of deadlock failure while dropping a partitioned index.
commit : 2241e5ceda2febd90b06e6cbc02a8b51e9e070e4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Mar 2022 12:22:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Mar 2022 12:22:13 -0400
DROP INDEX needs to lock the index's table before the index itself,
else it will deadlock against ordinary queries that acquire the
relation locks in that order. This is correctly mechanized for
plain indexes by RangeVarCallbackForDropRelation; but in the case of
a partitioned index, we neglected to lock the child tables in advance
of locking the child indexes. We can fix that by traversing the
inheritance tree and acquiring the needed locks in RemoveRelations,
after we have acquired our locks on the parent partitioned table and
index.
While at it, do some refactoring to eliminate confusion between
the actual and expected relkind in RangeVarCallbackForDropRelation.
We can save a couple of syscache lookups too, by having that function
pass back info that RemoveRelations will need.
Back-patch to v11 where partitioned indexes were added.
Jimmy Yih, Gaurab Dey, Tom Lane
Discussion: https://postgr.es/m/BYAPR05MB645402330042E17D91A70C12BD5F9@BYAPR05MB6454.namprd05.prod.outlook.com
M src/backend/commands/tablecmds.c
A src/test/isolation/expected/partition-drop-index-locking.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/partition-drop-index-locking.spec
Doc: fix our example systemd script.
commit : 36c3acb397e15ee7f7d5545b4775eecc2ded917f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Mar 2022 12:39:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Mar 2022 12:39:40 -0400
The example used "TimeoutSec=0", but systemd's documented way to get
the desired effect is "TimeoutSec=infinity".
Discussion: https://postgr.es/m/164770078557.670.5467111518383664377@wrigleys.postgresql.org
M doc/src/sgml/runtime.sgml
doc: Mention SET TABLESPACE clause for ALTER MATERIALIZED VIEW
commit : fe14b0dd45a8d028d7ae49b68e445f78e8535015
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 19 Mar 2022 16:37:43 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 19 Mar 2022 16:37:43 +0900
This command flavor is supported, but there was nothing in the
documentation about it.
Author: Yugo Nagata
Discussion: https://postgr.es/m/20220316133337.5dc9740abfa24c25ec9f67f5@sraoss.co.jp
Backpatch-through: 10
M doc/src/sgml/ref/alter_materialized_view.sgml
Fix incorrect xmlschema output for types timetz and timestamptz.
commit : 88ae77588d9a891c492f8ba543b3c1064c7a8ef3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Mar 2022 16:01:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Mar 2022 16:01:42 -0400
The output of table_to_xmlschema() and allied functions includes
a regex describing valid values for these types ... but the regex
was itself invalid, as it failed to escape a literal "+" sign.
Report and fix by Renan Soares Lopes. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/7f6fabaa-3f8f-49ab-89ca-59fbfe633105@me.com
M src/backend/utils/adt/xml.c
M src/test/regress/expected/xmlmap.out
M src/test/regress/expected/xmlmap_1.out
M src/test/regress/sql/xmlmap.sql
Revert applying column aliases to the output of whole-row Vars.
commit : 5e144cc89b468d845a2dbd7bdd1786c6efcdfd83
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Mar 2022 18:18:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Mar 2022 18:18:05 -0400
In commit bf7ca1587, I had the bright idea that we could make the
result of a whole-row Var (that is, foo.*) track any column aliases
that had been applied to the FROM entry the Var refers to. However,
that's not terribly logically consistent, because now the output of
the Var is no longer of the named composite type that the Var claims
to emit. bf7ca1587 tried to handle that by changing the output
tuple values to be labeled with a blessed RECORD type, but that's
really pretty disastrous: we can wind up storing such tuples onto