Ignore dropped columns during apply of update/delete.
commit : 65ead76961a4be9a10d1c7dbfdcb10765aad8af9
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Mar 2023 09:18:51 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Mar 2023 09:18:51 +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 : 1b9e42e82ae62f2a53e4a3da19b5fff994af5d72
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
Fix netmask handling in inet_minmax_multi_ops
commit : 6a78a42fea0c457dfee2a5ac5431df02342eafd2
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Mon, 20 Mar 2023 09:51:50 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Mon, 20 Mar 2023 09:51:50 +0100
When calculating distance in brin_minmax_multi_distance_inet(), the
netmask was applied incorrectly. This results in (seemingly) incorrect
ordering of values, triggering an assert.
For builds without asserts this is mostly harmless - we may merge other
ranges, possibly resulting in slightly less efficient index. But it's
still correct and the greedy algorithm doesn't guarantee optimality
anyway.
Backpatch to 14, where minmax-multi indexes were introduced.
Reported by Dmitry Dolgov, investigation and fix by me.
Reported-by: Dmitry Dolgov
Backpatch-through: 14
Discussion: https://postgr.es/m/17774-c6f3e36dd4471e67@postgresql.org
M src/backend/access/brin/brin_minmax_multi.c
M src/test/regress/expected/brin_multi.out
M src/test/regress/sql/brin_multi.sql
Fix memory leak in Memoize cache key evaluation
commit : f654f343c6a89f76aa0385bb92a1c6802126974c
author : David Rowley <drowley@postgresql.org>
date : Mon, 20 Mar 2023 13:30:55 +1300
committer: David Rowley <drowley@postgresql.org>
date : Mon, 20 Mar 2023 13:30:55 +1300
When probing the Memoize cache to check if the current cache key values
exist in the cache, we perform an evaluation of the expressions making up
the cache key before probing the hash table for those values. This
operation could leak memory as it is possible that the cache key is an
expression which requires allocation of memory, as was the case in bug
17844.
Here we fix this by correctly switching to the per tuple context before
evaluating the cache expressions so that the memory is freed next time the
per tuple context is reset.
Bug: 17844
Reported-by: Alexey Ermakov
Discussion: https://postgr.es/m/17844-d2f6f9e75a622bed@postgresql.org
Backpatch-through: 14, where Memoize was introduced
M src/backend/executor/nodeMemoize.c
Doc: fix documentation example for bytea hex output format.
commit : 6fe609496beadfe85124290f220a25075d7f2c04
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 : 5fc1ac151d85a4da8724e1d886fbb6fe3ff519c0
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 : a9b716c33d6d1bb02cd604517326dc1938f9abea
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 : e304e5099258f92a8f7be801ef72c920b299d1d7
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 : 1c0d4affa22a177b0ac6f08f801ccaacf2217c43
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 : a7a92738ffce35b480d20965ad95317729ae96a2
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 : 00fc4b3a31010033e8b1a964c90a7a30b8d6a7d7
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
Doc: mention CREATE+ATTACH PARTITION with CREATE TABLE...PARTITION OF.
commit : 8f90381a20b259decfbb7174034ca7c457a041d0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 Mar 2023 16:50:56 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 Mar 2023 16:50:56 -0400
Clarify that ATTACH/DETACH PARTITION can be used to perform partition
maintenance with less locking than straight CREATE TABLE/DROP TABLE.
This was already stated in some places, but not emphasized.
Back-patch to v14 where DETACH PARTITION CONCURRENTLY was added.
(We had lower lock levels for ATTACH PARTITION before that, but
this wording wouldn't apply.)
Justin Pryzby, reviewed by Robert Treat and Jakub Wartak;
a little further wordsmithing by me
Discussion: https://postgr.es/m/20220718143304.GC18011@telsasoft.com
M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_table.sgml
Improve WIN32 port of fstat() to detect more file types
commit : bbf18fe199c5844a39c8cb1aa60e5a13da8103c8
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 15 Mar 2023 12:56:10 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 15 Mar 2023 12:56:10 +0900
The current implementation of _pgfstat64() is ineffective in detecting a
terminal handle or an anonymous named pipe. This commit improves our
port of fstat() to detect more efficiently such cases by relying on
GetFileType(), and returning more correct data when the type found is
either a FILE_TYPE_PIPE (_S_IFIFO) or a FILE_TYPE_CHAR (_S_IFCHR).
This is part of a more global fix to address failures when feeding the
output generated by pg_dump to pg_restore through a pipe, for example,
but not all of it. We are also going to need to do something about
fseek() and ftello() which are not reliable on WIN32 for the same cases
where fstat() was incorrect. Fixing fstat() is independent of the rest,
though, which is why both fixes are handled separately, and this is the
first part of it.
Reported-by: Daniel Watzinger
Author: Daniel Watzinger, Juan José Santamaría Flecha
Discussion: https://postgr.es/m/b1448cd7-871e-20e3-8398-895e2d1d3bf9@gmail.com
Backpatch-through: 14
M src/port/win32stat.c
Fix fractional vacuum_cost_delay.
commit : 2bef57ee8b38ee7fdbad3fb38b1f8ed31adb381b
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 15 Mar 2023 13:57:00 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 15 Mar 2023 13:57:00 +1300
Commit 4753ef37 changed vacuum_delay_point() to use the WaitLatch() API,
to fix the problem that vacuum could keep running for a very long time
after the postmaster died.
Unfortunately, that broke commit caf626b2's support for fractional
vacuum_cost_delay, which shipped in PostgreSQL 12. WaitLatch() works in
whole milliseconds.
For now, revert the change from commit 4753ef37, but add an explicit
check for postmaster death. That's an extra system call on systems
other than Linux and FreeBSD, but that overhead doesn't matter much
considering that we willingly went to sleep and woke up again. (In
later work, we might add higher resolution timeouts to the latch API so
that we could do this with our standard programming pattern, but that
wouldn't be back-patched.)
Back-patch to 14, where commit 4753ef37 arrived.
Reported-by: Melanie Plageman <melanieplageman@gmail.com>
Discussion: https://postgr.es/m/CAAKRu_b-q0hXCBUCAATh0Z4Zi6UkiC0k2DFgoD3nC-r3SkR3tg%40mail.gmail.com
M src/backend/commands/vacuum.c
Fix waitpid() emulation on Windows.
commit : 9b6e0b9c37d644bc99f7c79e01b388f6a3648387
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 : 7cac191057ea8d6f2358f0504039d29e6c5e2141
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
Remove unnecessary code in dependency_is_compatible_expression().
commit : 7c509f7e5a817ea676479d33bb975d72785ff106
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Mar 2023 11:10:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Mar 2023 11:10:45 -0400
Scanning the expression for compatible Vars isn't really necessary,
because the subsequent match against StatisticExtInfo entries will
eliminate expressions containing other Vars just fine. Moreover,
this code hadn't stopped to think about what to do with
PlaceHolderVars or Aggrefs in the clause; and at least for the PHV
case, that demonstrably leads to failures. Rather than work out
whether it's reasonable to ignore those, let's just remove the
whole stanza.
Per report from Richard Guo. Back-patch to v14 where this code
was added.
Discussion: https://postgr.es/m/CAMbWs48Mmvm-acGevXuwpB=g5JMqVSL6i9z5UaJyLGJqa-XPAA@mail.gmail.com
M src/backend/statistics/dependencies.c
Fix JSON error reporting for many cases of erroneous string values.
commit : 0ee9d685dd80910a269eb44036dc59df511c6d88
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/backend/utils/adt/jsonfuncs.c
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 : 096e708056ead615f82a851d0825d9d6b40f7c96
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 : 7e319231c6bba7bad4a71a47ed0aefadf71e1103
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 13 Mar 2023 16:36:31 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 13 Mar 2023 16:36:31 +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 : 4642c2b56a99a2bd86111f8c46f377e2fc362463
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
amcheck: Fix FullTransactionIdFromXidAndCtx() for xids before epoch 0
commit : b3a83055c23526787701cd93e76a6df4f5a85920
author : Andres Freund <andres@anarazel.de>
date : Sat, 11 Mar 2023 14:12:51 -0800
committer: Andres Freund <andres@anarazel.de>
date : Sat, 11 Mar 2023 14:12:51 -0800
64bit xids can't represent xids before epoch 0 (see also be504a3e974). When
FullTransactionIdFromXidAndCtx() was passed such an xid, it'd create a 64bit
xid far into the future. Noticed while adding assertions in the course of
investigating be504a3e974, as amcheck's test create such xids.
To fix the issue, just return FirstNormalFullTransactionId in this case. A
freshly initdb'd cluster already has a newer horizon. The most minimal version
of this would make the messages for some detected corruptions differently
inaccurate. To make those cases accurate, switch
FullTransactionIdFromXidAndCtx() to use the 32bit modulo difference between
xid and nextxid to compute the 64bit xid, yielding sensible "in the future" /
"in the past" answers.
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>
Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de
Backpatch: 14-, where heapam verification was introduced
M contrib/amcheck/verify_heapam.c
M src/bin/pg_amcheck/t/004_verify_heapam.pl
amcheck: Fix ordering bug in update_cached_xid_range()
commit : a42f515d6b45ea19b96fb2868d8acb77251d911d
author : Andres Freund <andres@anarazel.de>
date : Sat, 11 Mar 2023 14:12:51 -0800
committer: Andres Freund <andres@anarazel.de>
date : Sat, 11 Mar 2023 14:12:51 -0800
The initialization order in update_cached_xid_range() was wrong, calling
FullTransactionIdFromXidAndCtx() before setting
->next_xid. FullTransactionIdFromXidAndCtx() uses ->next_xid.
In most situations this will not cause visible issues, because the next call
to update_cached_xid_range() will use a less wrong ->next_xid. It's rare that
xids advance fast enough for this to be a problem.
Found while adding more asserts to the 64bit xid infrastructure.
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>
Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de
Backpatch: 14-, where heapam verification was introduced
M contrib/amcheck/verify_heapam.c
Fix misbehavior in contrib/pg_trgm with an unsatisfiable regex.
commit : 786528039911c2270589bb690afab20116ee88f3
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 : 53a53ea332131b3d29d8d69e1dc2823f4d6ff21a
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/backend/commands/copyto.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Fix race in SERIALIZABLE READ ONLY.
commit : d811d74be353283a3c8282b46a0a6e75e89de5f9
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 : 324281fd5b1b413b70910b8c59d00900efedd256
author : Andres Freund <andres@anarazel.de>
date : Tue, 7 Mar 2023 21:36:49 -0800
committer: Andres Freund <andres@anarazel.de>
date : Tue, 7 Mar 2023 21:36:49 -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/storage/ipc/procarray.c
Fix more bugs caused by adding columns to the end of a view.
commit : 9f1e51b5967345afc42efb6c146043b5bcd91679
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 : 1e05ea51d327635ce56caab56cc47e70716e081f
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 : e9051ecd58e9f171c5c92f28c1bbd8f42fa243c1
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
pageinspect: Fix crash with gist_page_items()
commit : 5ad63eee13e70eeff9659bcee024e8249b6bf68c
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 2 Mar 2023 14:03:21 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 2 Mar 2023 14:03:21 +0900
Attempting to use this function with a raw page not coming from a GiST
index would cause a crash, as it was missing the same sanity checks as
gist_page_items_bytea(). This slightly refactors the code so as all the
basic validation checks for GiST pages are done in a single routine,
in the same fashion as the pageinspect functions for hash and BRIN.
This fixes an issue similar to 076f4d9. A test is added to stress for
this case. While on it, I have added a similar test for
brin_page_items() with a combination make of a valid GiST index and a
raw btree page. This one was already protected, but it was not tested.
Reported-by: Egor Chindyaskin
Author: Dmitry Koval
Discussion: https://postgr.es/m/17815-fc4a2d3b74705703@postgresql.org
Backpatch-through: 14
M contrib/pageinspect/expected/brin.out
M contrib/pageinspect/expected/gist.out
M contrib/pageinspect/gistfuncs.c
M contrib/pageinspect/sql/brin.sql
M contrib/pageinspect/sql/gist.sql
Avoid fetching one past the end of translate()'s "to" parameter.
commit : 1a9356f657e19ae1abeb0ffea0b7edaf69e315cb
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
Harden postgres_fdw tests against unexpected cache flushes.
commit : ba019b4dacf637459148f1327f9345bff031dfe2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 27 Feb 2023 16:29:51 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 27 Feb 2023 16:29:51 -0500
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
Don't force SQL_ASCII/no-locale for installcheck in vcregress.pl
commit : 4d68338b26a93f79ad818a462fa96d84ffa2ac51
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 : 9eaba06027ae01476a20725e54261e4f64ea023b
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/include/nodes/primnodes.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 : 27ff93d18c2ba921cfbb9e2e38f5fb66c130bc9f
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 25 Feb 2023 14:44:49 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 25 Feb 2023 14:44:49 +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 : 0f78df719a90e3f992304f63b146b178e676bed2
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 : f0423bea7f0afe6ccd830e2b729180e4355e04f6
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 23 Feb 2023 10:55:48 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 23 Feb 2023 10:55:48 +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 : 8b9cbd42b61ff55e5519631bada5d310159e3a5f
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 : 482ab3e4f9e0a2fcef96bdcbe7a719858fae8f79
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 22 Feb 2023 13:26:20 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 22 Feb 2023 13:26:20 +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 : dc44180f6e17e10189c2e64a61255985de518a1e
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
pgbench: Prepare commands in pipelines in advance
commit : 663e50e8321192f30559a7dd68a912c43a44dcbb
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 21 Feb 2023 10:56:37 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 21 Feb 2023 10:56:37 +0100
Failing to do so results in an error when a pgbench script tries to
start a serializable transaction inside a pipeline, because by the time
BEGIN ISOLATION LEVEL SERIALIZABLE is executed, we're already in a
transaction that has acquired a snapshot, so the server rightfully
complains.
We can work around that by preparing all commands in the pipeline before
actually starting the pipeline. This changes the existing code in two
aspects: first, we now prepare each command individually at the point
where that command is about to be executed; previously, we would prepare
all commands in a script as soon as the first command of that script
would be executed. It's hard to see that this would make much of a
difference (particularly since it only affects the first time to execute
each script in a client), but I didn't actually try to measure it.
Secondly, we no longer use PQsendPrepare() in pipeline mode, but only
PQprepare. There's no specific reason for this change other than no
longer needing to do differently in pipeline mode. (Previously we had
no choice, because in pipeline mode PQprepare could not be used.)
Backpatch to 14, where pgbench got support for pipeline mode.
Reported-by: Yugo NAGATA <nagata@sraoss.co.jp>
Discussion: https://postgr.es/m/20210716153013.fc53b1c780b06fccc07a7f0d@sraoss.co.jp
M src/bin/pgbench/pgbench.c
M src/bin/pgbench/t/001_pgbench_with_server.pl
Fix handling of multi-column BRIN indexes
commit : f3daa3116fad6aa85686aba5b54eaecc07e8f6cf
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 19 Feb 2023 00:41:18 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 19 Feb 2023 00:41:18 +0100
When evaluating clauses on multiple scan keys of a multi-column BRIN
index, we can stop processing as soon as we find a scan key eliminating
the range, and the range should not be added to tbe bitmap.
That's how it worked before 14, but since a681e3c107a the code treated
the range as matching if it matched at least the last scan key.
Backpatch to 14, where this code was introduced.
Backpatch-through: 14
Discussion: https://postgr.es/m/ebc18613-125e-60df-7520-fcbe0f9274fc%40enterprisedb.com
M src/backend/access/brin/brin.c
Print the correct aliases for DML target tables in ruleutils.
commit : 14345f3c6a7bc967b168bb1ed40de369a8998941
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 : 864f80feadea85fae70abe3fa9d89408b93547d2
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 15 Feb 2023 10:12:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 15 Feb 2023 10:12:33 +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.ac
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 : 4aa43ba21846ac6cc53c554565898a294ded6ad1
author : David Rowley <drowley@postgresql.org>
date : Mon, 13 Feb 2023 17:09:55 +1300
committer: David Rowley <drowley@postgresql.org>
date : Mon, 13 Feb 2023 17:09:55 +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 : 7f8778fcf3428756c1c9ab1ee26ff328e00bf608
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 : 0801345758db44ea8d2da7d8e7d8be2cf3d9bc4e
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 8 Feb 2023 13:09:27 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 8 Feb 2023 13:09:27 +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.ac
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 14.7.
commit : e4c4e6258c747d440e161f387d2eff84a835ca08
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2023 16:41:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2023 16:41:14 -0500
M configure
M configure.ac
Last-minute updates for release notes.
commit : dfb5ad7cf0d83ac3bb78f0177721f68a6ba60486
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-14.sgml
Translation updates
commit : 28ac6d0a99d57375dbd9bc2acd16fd1127502ef7
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 6 Feb 2023 12:17:21 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 6 Feb 2023 12:17:21 +0100
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 8ae33814b61e2eabfaac363c777e0cbf346761de
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 : 626f2c1d6b85a6a0780460c7acc306bc2c326266
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 6 Feb 2023 11:20:23 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 6 Feb 2023 11:20:23 +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 : e8c21223e758000be6040785f2cfd0916dc05e97
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-14.sgml
Make int64_div_fast_to_numeric() more robust.
commit : 86bfbeab4f439ad527318d9edeb3c71ea46c1ab3
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 3 Feb 2023 11:09:15 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 3 Feb 2023 11:09:15 +0000
The prior coding of int64_div_fast_to_numeric() had a number of bugs
that would cause it to fail under different circumstances, such as
with log10val2 <= 0, or log10val2 a multiple of 4, or in the "slow"
numeric path with log10val2 >= 10.
None of those could be triggered by any of our current code, which
only uses log10val2 = 3 or 6. However, they made it a hazard for any
future code that might use it. Also, since this is exported by
numeric.c, users writing their own C code might choose to use it.
Therefore fix, and back-patch to v14, where it was introduced.
Dean Rasheed, reviewed by Tom Lane.
Discussion: https://postgr.es/m/CAEZATCW8gXgW0tgPxPgHDPhVX71%2BSWFRkhnXy%2BTfGDsKLepu2g%40mail.gmail.com
M src/backend/utils/adt/numeric.c
doc: Fix XML formatting that psql cannot handle
commit : 89d28f928c402e9f1890ece4d787825a6c51c2ca
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
Doc: Abstract AF_UNIX sockets don't work on Windows.
commit : 36c910f037836ed1b4143f40af43df488c9fbd6c
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 2 Feb 2023 18:13:44 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 2 Feb 2023 18:13:44 +1300
An early release of AF_UNIX in Windows apparently supported Linux-style
"abstract" Unix sockets, but they do not seem to work in current Windows
versions and there is no mention of any of this in the Winsock
documentation. Remove the mention of Windows from the documentation.
Back-patch to 14, where commit c9f0624b landed.
Discussion: https://postgr.es/m/CA%2BhUKGKrYbSZhrk4NGfoQGT_3LQS5pC5KNE1g0tvE_pPBZ7uew%40mail.gmail.com
M doc/src/sgml/config.sgml
Update time zone data files to tzdata release 2022g.
commit : 7e615477996b51487e67e36490be9a4f33114529
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 : 26da294098882c28467ad07995dbc80742db1d57
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 : 96d42bd27fefed662dbf690348186902d4b6954e
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 31 Jan 2023 12:47:12 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 31 Jan 2023 12:47:12 +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 : 2f65b84683b7e755b4c44dc949f567e6d5d50132
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
doc: Fix network_ops -> inet_ops in SpGiST operator class list
commit : e9774151c27868ebec08259f3698ebdb321138c4
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 25 Jan 2023 20:00:46 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 25 Jan 2023 20:00:46 +0900
network_ops is an opclass family of SpGiST, and the opclass able to
work on the inet type is named inet_ops.
Oversight in 7a1cd52, that reworked the design of the table listing all
the operators available.
Reported-by: Laurence Parry
Reviewed-by: Tom Lane, David G. Johnston
Discussion: https://postgr.es/m/167458110639.2667300.14741268666497110766@wrigleys.postgresql.org
Backpatch-through: 14
M doc/src/sgml/spgist.sgml
Fix the Drop Database hang.
commit : fd270b728b28bd1a2973837498977de67d0a887e
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 24 Jan 2023 08:55:55 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 24 Jan 2023 08:55:55 +0530
The drop database command waits for the logical replication sync worker to
accept ProcSignalBarrier and the worker's slot creation waits for the drop
database to finish which leads to a deadlock. This happens because the
tablesync worker holds interrupts while creating a slot.
We prevent cancel/die interrupts while creating a slot in the table sync
worker because it is possible that before the server finishes this
command, a concurrent drop subscription happens which would complete
without removing this slot and that leads to the slot existing until the
end of walsender. However, the slot will eventually get dropped at the
walsender exit time, so there is no danger of the dangling slot.
This patch reallows cancel/die interrupts while creating a slot and
modifies the test to wait for slots to become zero to prevent finding an
ephemeral slot.
The reported hang doesn't happen in PG14 as the drop database starts to
wait for ProcSignalBarrier with PG15 (commits 4eb2176318 and e2f65f4255)
but it is good to backpatch this till PG14 as it is not a good idea to
prevent interrupts during a network call that could block indefinitely.
Reported-by: Lakshmi Narayanan Sreethar
Diagnosed-by: Andres Freund
Author: Hou Zhijie
Reviewed-by: Vignesh C, Amit Kapila
Backpatch-through: 14, where it was introduced in commit 6b67d72b60
Discussion: https://postgr.es/m/CA+kvmZELXQ4ZD3U=XCXuG3KvFgkuPoN1QrEj8c-rMRodrLOnsg@mail.gmail.com
M src/backend/replication/logical/tablesync.c
M src/test/subscription/t/004_sync.pl
Fix error handling in libpqrcv_connect()
commit : 0a796b8b3e311ea21cf679bf71f39b42e859a686
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
Use OFFSET 0 instead of ORDER BY to stop subquery pullup
commit : 0765b2f8f6fe8b7c1c07f94b764ef8bb74a292b4
author : David Rowley <drowley@postgresql.org>
date : Tue, 24 Jan 2023 13:50:11 +1300
committer: David Rowley <drowley@postgresql.org>
date : Tue, 24 Jan 2023 13:50:11 +1300
b762fed64 recently changed this test to prevent subquery pullup to allow
us to test Memoize with lateral_vars. As pointed out by Tom Lane, OFFSET
0 is our standard way of preventing subquery pullups, so do it that way
instead.
Discussion: https://postgr.es/m/2144818.1674517061@sss.pgh.pa.us
Backpatch-through: 14, same as b762fed64
M src/test/regress/expected/memoize.out
M src/test/regress/sql/memoize.sql
Fix LATERAL join test in test memoize.sql
commit : bcec08907e9357425ec0b3ea9ce03fd41fa6b8de
author : David Rowley <drowley@postgresql.org>
date : Tue, 24 Jan 2023 12:29:24 +1300
committer: David Rowley <drowley@postgresql.org>
date : Tue, 24 Jan 2023 12:29:24 +1300
The test in question was meant to be testing Memoize to ensure it worked
correctly when the inner side of the join contained lateral vars, however,
nothing in the lateral subquery stopped it from being pulled up into the
main query, so the planner did that, and that meant no more lateral vars.
Here we add a simple ORDER BY to stop the planner from being able to
pullup the lateral subquery.
Author: Richard Guo
Discussion: https://postgr.es/m/CAMbWs4_LHJaN4L-tXpKMiPFnsCJWU1P8Xh59o0W7AA6UN99=cQ@mail.gmail.com
Backpatch-through: 14, where Memoize was added.
M src/test/regress/expected/memoize.out
M src/test/regress/sql/memoize.sql
Allow REPLICA IDENTITY to be set on an index that's not (yet) valid.
commit : 70ec756b01a4c9e62c189a8d853401393d18cb4b
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 : 6900aea67e27990b72bc28b0b69096db9d226cba
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 : 21c058648ec2cd257b7b8bb10b98e08564a685a4
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
M src/include/utils/snapmgr.h
Log the correct ending timestamp in recovery_target_xid mode.
commit : 1034507245571a4a8e614299afe3f2e2ae858c27
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 : 2e21e2857e5657b6867b337ddce5a22afce320c6
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 13:13:28 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 13:13:28 +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 : efd2474ab5b40778722054659e52254840773f95
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 10:02:10 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 10:02:10 +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 : 1b62971bbc3163bbe31346846bc511386f6808cd
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 : 8e7398dce55b1d2a32a31f11179075086d112b66
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 : f463335e1f29b8f5b47d8b606d10cdf76817970f
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
M src/backend/replication/logical/worker.c
Make new GENERATED-expressions code more bulletproof.
commit : a8b88c26f7061689ef1aea1b8fd234fed8e1fc9e
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 : 547e60b8317e3c351900c650988327b73cf7ae33
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 : 0d9221f1d251b956a33660bff1420140f8abebcb
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
Remove the streaming files for incomplete xacts after restart.
commit : b2cc5b81001ad5e856d7316bab11f08ce1386d4b
author : Amit Kapila <akapila@postgresql.org>
date : Sat, 7 Jan 2023 11:52:41 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Sat, 7 Jan 2023 11:52:41 +0530
After restart, we try to stream the changes for large transactions that
were not sent before server crash and restart. However, we forget to send
the abort message for such transactions. This leads to spurious streaming
files on the subscriber which won't be cleaned till the apply worker or
the subscriber server restarts.
Reported-by: Dilip Kumar
Author: Hou Zhijie
Reviewed-by: Dilip Kumar and Amit Kapila
Backpatch-through: 14
Discussion: https://postgr.es/m/OS0PR01MB5716A773F46768A1B75BE24394FB9@OS0PR01MB5716.jpnprd01.prod.outlook.com
M src/backend/replication/logical/reorderbuffer.c
Fix tab completion of ALTER FUNCTION/PROCEDURE/ROUTINE ... SET SCHEMA.
commit : 48599a18d07999c7503b9f47ec43c0f19b603001
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 6 Jan 2023 11:15:22 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 6 Jan 2023 11:15:22 +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 pg_truncate() on Windows.
commit : af209b7893f45af04f1b6f6304e9882069111da7
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 6 Jan 2023 16:38:46 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 6 Jan 2023 16:38:46 +1300
Commit 57faaf376 added pg_truncate(const char *path, off_t length), but
"length" was ignored under WIN32 and the file was unconditionally
truncated to 0.
There was no live bug, since the only caller passes 0.
Fix, and back-patch to 14 where the function arrived.
Author: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20230106031652.GR3109%40telsasoft.com
M src/backend/storage/file/fd.c
Fix calculation of which GENERATED columns need to be updated.
commit : 8cd190e13a22dab12e86f7f1b59de6b9b128c784
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 : 5136c3fb575bb46f5f33c0485c972aa5dea0757a
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 : e373e5578bc39af4f20a4b70c5db1895d0e2d3d1
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 3 Jan 2023 16:26:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 3 Jan 2023 16:26:30 +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 : 7b5dec760f7d7cb8df0fe10051a6aca806581957
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 : a02740e53fb7d1668e2d0ea1362743d23211d43d
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 : fdaba0a2d749bff497313b584f86855a1440d43e
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Jan 2023 15:00:37 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Jan 2023 15:00:37 -0500
Backpatch-through: 11
M COPYRIGHT
M doc/src/sgml/legal.sgml
Fix assert in BRIN build_distances
commit : 883dc0214a64c0923455bf30bfcc5f953e70af39
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 30 Dec 2022 19:44:48 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 30 Dec 2022 19:44:48 +0100
When brin_minmax_multi_union merges summaries, we may end up with just a
single range after merge_overlapping_ranges. The summaries may contain
just one range each, and they may overlap (or be exactly the same).
With a single range there's no distance to calculate, but we happen to
call build_distances anyway - which is fine, we don't calculate the
distance in this case, except that with asserts this failed due to a
check there are at least two ranges.
The assert is unnecessarily strict, so relax it a bit and bail out if
there's just a single range. The relaxed assert would be enough, but
this way we don't allocate unnecessary memory for distance.
Backpatch to 14, where minmax-multi opclasses were introduced.
Reported-by: Jaime Casanova
Backpatch-through: 14
Discussion: https://postgr.es/m/YzVA55qS0hgz8P3r@ahch-to
M src/backend/access/brin/brin_minmax_multi.c
Fix event trigger example
commit : 169d301f3305b47eff0cddd48aa0a563a3c38d4b
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 : fd36b82c5d74ed355660beae79925a9faa36a084
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 11:27:14 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 11:27:14 +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 : 7ad458e06b1bf1408d9d089a843070943d6c7c6a
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 10:04:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 10:04:33 +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 : 97431d673992326f4f85e4f185941444f33e20db
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2022 10:35:02 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2022 10:35:02 -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 : f489b480f4aa8b4db4858a7bef1b42c984992c8a
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
Fix inability to reference CYCLE column from inside its CTE.
commit : ea5ae4cae6a230e048f0ff4587b54d441712c6fd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Dec 2022 13:07:42 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Dec 2022 13:07:42 -0500
Such references failed with "cache lookup failed for type 0"
because we didn't resolve the type of the CYCLE column until after
analyzing the CTE's query. We can just move that processing
to before the recursive parse_sub_analyze call, though.
While here, invent a couple of local variables to make this
code less egregiously wider-than-80-columns.
Per bug #17723 from Vik Fearing. Back-patch to v14 where
the CYCLE feature was added.
Discussion: https://postgr.es/m/17723-2c4985ff111e7bba@postgresql.org
M src/backend/parser/parse_cte.c
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql
Re-adjust drop-index-concurrently-1 isolation test
commit : 171d7746a21dfb0e19c008b7a398e1ee1ad7f74e
author : David Rowley <drowley@postgresql.org>
date : Fri, 16 Dec 2022 11:40:55 +1300
committer: David Rowley <drowley@postgresql.org>
date : Fri, 16 Dec 2022 11:40:55 +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 : ae47f8a9664a65b233ee3c716f3098a5ba71f615
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/libpq.sgml
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
Fix jsonb subscripting to cope with toasted subscript values.
commit : a18328bb3395188befc2785dbbe47f0d84baf6d1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Dec 2022 16:17:49 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Dec 2022 16:17:49 -0500
jsonb_get_element() was incautious enough to use VARDATA() and
VARSIZE() directly on an arbitrary text Datum. That of course
fails if the Datum is short-header, compressed, or out-of-line.
The typical result would be failing to match any element of a
jsonb object, though matching the wrong one seems possible as well.
setPathObject() was slightly brighter, in that it used VARDATA_ANY
and VARSIZE_ANY_EXHDR, but that only kept it out of trouble for
short-header Datums. push_path() had the same issue. This could
result in faulty subscripted insertions, though keys long enough to
cause a problem are likely rare in the wild.
Having seen these, I looked around for unsafe usages in the rest
of the adt/json* files. There are a couple of places where it's not
immediately obvious that the Datum can't be compressed or out-of-line,
so I added pg_detoast_datum_packed() to cope if it is. Also, remove
some other usages of VARDATA/VARSIZE on Datums we just extracted from
a text array. Those aren't actively broken, but they will become so
if we ever start allowing short-header array elements, which does not
seem like a terribly unreasonable thing to do. In any case they are
not great coding examples, and they could also do with comments
pointing out that we're assuming we don't need pg_detoast_datum_packed.
Per report from exe-dealer@yandex.ru. Patch by me, but thanks to
David Johnston for initial investigation. Back-patch to v14 where
jsonb subscripting was introduced.
Discussion: https://postgr.es/m/205321670615953@mail.yandex.ru
M src/backend/utils/adt/jsonb_gin.c
M src/backend/utils/adt/jsonb_op.c
M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/jsonb.sql
Remove new structure member from ResultRelInfo.
commit : d43a97ef493a7edc9e03b5dd15870e04a0c38f75
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 8 Dec 2022 16:15:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 8 Dec 2022 16:15:03 +0900
In commit ffbb7e65a, I added a ModifyTableState member to ResultRelInfo
to save the owning ModifyTableState for use by nodeModifyTable.c when
performing batch inserts, but as pointed out by Tom Lane, that changed
the array stride of es_result_relations, and that would break any
previously-compiled extension code that accesses that array. Fix by
removing that member from ResultRelInfo and instead adding a List member
at the end of EState to save such ModifyTableStates.
Per report from Tom Lane. Back-patch to v14, like the previous commit;
I chose to apply the patch to HEAD as well, to make back-patching easy.
Discussion: http://postgr.es/m/4065383.1669395453%40sss.pgh.pa.us
M src/backend/executor/execMain.c
M src/backend/executor/execPartition.c
M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/include/nodes/execnodes.h
Fix Memoize to work with partitionwise joining.
commit : dc3648f65bea3d3373b4e0026ae83bd8f436ee40
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Dec 2022 12:36:41 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Dec 2022 12:36:41 -0500
A couple of places weren't up to speed for this. By sheer good
luck, we didn't fail but just selected a non-memoized join plan,
at least in the test case we have. Nonetheless, it's a bug,
and I'm not quite sure that it couldn't have worse consequences
in other examples. So back-patch to v14 where Memoize came in.
Richard Guo
Discussion: https://postgr.es/m/CAMbWs48GkNom272sfp0-WeD6_0HSR19BJ4H1c9ZKSfbVnJsvRg@mail.gmail.com
M src/backend/optimizer/path/joinpath.c
M src/backend/optimizer/util/pathnode.c
M src/include/nodes/pathnodes.h
M src/test/regress/expected/memoize.out
M src/test/regress/sql/memoize.sql
doc: Add missing <varlistentry> markups for developer GUCs
commit : 1bd84ef6778017f89c2ca80377c3ae02ed3f4861
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 5 Dec 2022 11:23:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 5 Dec 2022 11:23:30 +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 broken MemoizePath support in reparameterize_path().
commit : ce093aa18062f64d5eb16175e361cc34a222c1db
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Dec 2022 13:48:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Dec 2022 13:48:12 -0500
It neglected to recurse to the subpath, meaning you'd get back
a path identical to the input. This could produce wrong query
results if the omission meant that the subpath fails to enforce
some join clause it should be enforcing. We don't have a test
case for this at the moment, but the code is obviously broken
and the fix is equally obvious. Back-patch to v14 where
Memoize was introduced.
Richard Guo
Discussion: https://postgr.es/m/CAMbWs4_R=ORpz=Lkn2q3ebPC5EuWyfZF+tmfCPVLBVK5W39mHA@mail.gmail.com
M src/backend/optimizer/util/pathnode.c
Fix generate_partitionwise_join_paths() to tolerate failure.
commit : ec3daeec316ff999d3e8f12a3587cdb4d0af81b0
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 : 2c7ed9f752924c038abffb46999a0f543139d797
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 3 Dec 2022 12:16:07 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 3 Dec 2022 12:16:07 +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 : 6344bc0974dcdf1854d7e5312d5233d2c097a328
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 psql's \sf and \ef for new-style SQL functions.
commit : 303b26c1bb14abf20a35a9cddebee65e10f5ebd4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Dec 2022 14:24:44 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Dec 2022 14:24:44 -0500
Some options of these commands need to be able to identify the start
of the function body within the output of pg_get_functiondef().
It used to be that that always began with "AS", but since the
introduction of new-style SQL functions, it might also start with
"BEGIN" or "RETURN". Fix that on the psql side, and add some
regression tests.
Noted by me awhile ago, but I didn't do anything about it.
Thanks to David Johnston for a nag.
Discussion: https://postgr.es/m/AM9PR01MB8268D5CDABDF044EE9F42173FE8C9@AM9PR01MB8268.eurprd01.prod.exchangelabs.com
M src/backend/utils/adt/ruleutils.c
M src/bin/psql/command.c
M src/test/regress/expected/psql.out
M src/test/regress/sql/psql.sql
Fix memory leak for hashing with nondeterministic collations.
commit : 47e1224d590ccbc0d745e812dffe2fa913201776
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 : 7ec2bfe9e0315a296a70e0f716e6dbe3ecfcd530
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
Fix under-parenthesized display of AT TIME ZONE constructs.
commit : de0ff6088e324f5f879c070e3369bc7ad8136b1b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Dec 2022 11:38:06 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Dec 2022 11:38:06 -0500
In commit 40c24bfef, I forgot to use get_rule_expr_paren() for the
arguments of AT TIME ZONE, resulting in possibly not printing parens
for expressions that need it. But get_rule_expr_paren() wouldn't have
gotten it right anyway, because isSimpleNode() hadn't been taught that
COERCE_SQL_SYNTAX parent nodes don't guarantee sufficient parentheses.
Improve all that. Also use this methodology for F_IS_NORMALIZED, so
that we don't print useless parens for that.
In passing, remove a comment that was obsoleted later.
Per report from Duncan Sands. Back-patch to v14 where this code
came in. (Before that, we didn't try to print AT TIME ZONE that way,
so there was no bug just ugliness.)
Discussion: https://postgr.es/m/f41566aa-a057-6628-4b7c-b48770ecb84a@deepbluecap.com
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
revert: add transaction processing chapter with internals info
commit : cf9bcb0f0421af15d7b9bebe00c8cf649bee399d
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 : a949b7320fdfad445453375a1630f81f6bd3b49d
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 : 5d208b90b75b00ff96095e4402a7cfa55f65f2ac
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 : cdea14a245b17df6d86f6c1193bc3726d4686605
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 30 Nov 2022 08:38:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 30 Nov 2022 08:38:30 +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 : 06998eab16b2165b5f27014a0843b75e377cc63e
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
Prevent clobbering of utility statements in SQL function caches.
commit : 7715a3c244507a52e64fbfe36547ec09eafd4af0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2022 11:46:33 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2022 11:46:33 -0500
This is an oversight in commit 7c337b6b5: I apparently didn't think
about the possibility of a SQL function being executed multiple
times within a query. In that case, functions.c's primitive caching
mechanism allows the same utility parse tree to be presented for
execution more than once. We have to tell ProcessUtility to make
a working copy of the parse tree, or bad things happen.
Normally I'd add a regression test, but I think the reported crasher
is dependent on some rather random implementation choices that are
nowhere near functions.c, so its usefulness as a long-lived test
feels questionable. In any case, this fix is clearly correct given
the design choices of 7c337b6b5.
Per bug #17702 from Xin Wen. Thanks to Daniel Gustafsson for
analysis. Back-patch to v14 where the faulty commit came in
(before that, the responsibility for copying scribble-able
utility parse trees lay elsewhere).
Discussion: https://postgr.es/m/17702-ad24fdcdd1e9047a@postgresql.org
M src/backend/executor/functions.c
Remove bogus Assert and dead code in remove_useless_results_recurse().
commit : 0224646beec657fb3a7791d237293ad4caea3255
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 : f3f70b8de66c0bae86f4761e152c10dd39f6f179
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 : 4e9e1b2a625eccfdfd09b8fca9693dd1fe96f256
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 : ec7b29cb954fca911fddb9a76a19170256338c8f
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 : f76191fd994aa1e49110b496f6c7119052118dee
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 handling of pending inserts in nodeModifyTable.c.
commit : e52245228ecf3a58b031c820332bc56478bb1ba2
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 25 Nov 2022 17:45:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 25 Nov 2022 17:45:03 +0900
Commit b663a4136, which allowed FDWs to INSERT rows in bulk, added to
nodeModifyTable.c code to flush pending inserts to the foreign-table
result relation(s) before completing processing of the ModifyTable node,
but the code failed to take into account the case where the INSERT query
has modifying CTEs, leading to incorrect results.
Also, that commit failed to flush pending inserts before firing BEFORE
ROW triggers so that rows are visible to such triggers.
In that commit we scanned through EState's
es_tuple_routing_result_relations or es_opened_result_relations list to
find the foreign-table result relations to which pending inserts are
flushed, but that would be inefficient in some cases. So to fix, 1) add
a List member to EState to record the insert-pending result relations,
and 2) modify nodeModifyTable.c so that it adds the foreign-table result
relation to the list in ExecInsert() if appropriate, and flushes pending
inserts properly using the list where needed.
While here, fix a copy-and-pasteo in a comment in ExecBatchInsert(),
which was added by that commit.
Back-patch to v14 where that commit appeared.
Discussion: https://postgr.es/m/CAPmGK16qutyCmyJJzgQOhfBq%3DNoGDqTB6O0QBZTihrbqre%2BoxA%40mail.gmail.com
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/executor/execMain.c
M src/backend/executor/execPartition.c
M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/include/nodes/execnodes.h
Fix uninitialized access to InitialRunningXacts during decoding.
commit : 9f2cc1a73ccf84c24dc4c386721b3bb73757dc24
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 25 Nov 2022 09:25:50 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 25 Nov 2022 09:25:50 +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 : 8e7c86785a11cd3e56f895b8e2a489546c36a350
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 : c93254424f288557eeef13343be8f72536cb9ffe
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 : bd06fe4dee6321a3eabc1832f1faa736350d5d2c
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 : 870d6218e6d73dca8ec37b4d7f5076b74eeaeffe
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 : 1b3ed757145dd6fa29feb6a31084527a6d6a46e3
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 : 385b317715179fd60b6a2899a3d10b13ca52ad4d
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 : 1b9c04b1389b0e8ee7f493477c22c25f65a2f89a
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
Revert "Prevent instability in contrib/pageinspect's regression test."
commit : 47a22dc2cb89aca2e54c9cf9fe2da4a5e8ba4cb4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2022 15:37:48 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2022 15:37:48 -0500
This reverts commit 5cda142bb9d2bd7e7ed1c22ae89afe58abfa8d7b
(in v14 only).
It turns out that that fails under force_parallel_mode = regress,
because pageinspect's disk-access functions are marked parallel
safe, which they are not if you try to use them on a temp table.
The cost of fixing that pre-v15 seems to exceed the value of
making this test case fully stable, so we will just leave things
as-is in v14.
M contrib/pageinspect/expected/page.out
M contrib/pageinspect/sql/page.sql
Prevent instability in contrib/pageinspect's regression test.
commit : 5cda142bb9d2bd7e7ed1c22ae89afe58abfa8d7b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2022 10:50:50 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2022 10:50:50 -0500
pageinspect has occasionally failed on slow buildfarm members,
with symptoms indicating that the expected effects of VACUUM
FREEZE didn't happen. This is presumably because a background
transaction such as auto-analyze was holding back global xmin.
We can work around that by using a temp table in the test.
Since commit a7212be8b, that will use an up-to-date cutoff xmin
regardless of other processes. And pageinspect itself shouldn't
really care whether the table is temp.
Back-patch to v14. There would be no point in older branches
without back-patching a7212be8b, which seems like more trouble
than the problem is worth.
Discussion: https://postgr.es/m/2892135.1668976646@sss.pgh.pa.us
M contrib/pageinspect/expected/page.out
M contrib/pageinspect/sql/page.sql
Fix mislabeling of PROC_QUEUE->links as PGPROC, fixing UBSan on 32bit
commit : fc4154286e0e47d748d19183fd05be794a019be8
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 : bb3f42aae382106b91d60b861333a08ff6007e9c
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 : 03ac48549438f26b796c1f536c2b545c6c50f259
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 : 55f30e6c7640c80fbb7be90fad668ee4bffa0e97
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
Fix version comparison in Version.pm
commit : 038512f71ea807d6c2b8e519f2416a9a5283d9bf
author : Andrew Dunstan <andrew@dunslane.net>
date : Fri, 18 Nov 2022 08:38:26 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Fri, 18 Nov 2022 08:38:26 -0500
Version strings with unequal numbers of parts were being compared
incorrectly. We cure this by treating a missing part in the shorter
version as 0.
per complaint from Jehan-Guillaume de Rorthais, but the fix is mine, not
his.
Discussion: https://postgr.es/m/20220628225325.53d97b8d@karst
Backpatch to release 14 where this code was introduced.
M src/test/perl/PostgresVersion.pm
Replace RelationOpenSmgr() with RelationGetSmgr().
commit : 32d5a4974c81aeaca7ffc025f0a5fda88b71cba6
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 : aaf28c90654425c2e94dc2c8b2d0d8d971483c7e
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 : 9693f190076ec04fd06d63ab00ba4d0383515b7c
author : Amit Kapila <akapila@postgresql.org>
date : Mon, 14 Nov 2022 10:22:28 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Mon, 14 Nov 2022 10:22:28 +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 : f893af496100737b7fa1ef861ac8bd2705b4d5f1
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 : 3383cf023484d595cc58ff47a9aa76ce5ed5bcf3
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 : 06dca17ad547ec7cf75d2e88436d28be9d1a51c9
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
Fix comments atop ReorderBufferAddInvalidations.
commit : fc0d1ecb0bf1b0d9f8271b81735a8eb8b304ad70
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 10 Nov 2022 17:19:30 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 10 Nov 2022 17:19:30 +0530
The comments atop seem to indicate that we always accumulate invalidation
messages in a top-level transaction which is neither required nor matches
with the code.
Author: Amit Kapila
Reviewd by: Masahiko Sawada
Backpatch-through: 14, where it was introduced in commit c55040ccd0
Discussion: https://postgr.es/m/CAA4eK1LxGgnUroPz8STb6OfjVU1yaHoSA+T63URwmGCLdMJ0LA@mail.gmail.com
M src/backend/replication/logical/reorderbuffer.c
Fix comment of SimpleLruInit() in slru.c
commit : 9e0321135cae1328cd4355399561428b474fce43
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 10 Nov 2022 16:33:55 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 10 Nov 2022 16:33:55 +0900
sync_handler was not mentioned in the comment block of the function.
Oversight in dee663f.
Author: Aleksander Alekseev
Discussion: https://postgr.es/m/CAJ7c6TPUd9BwNY47TtMxaijLHSbyHNdhu=kvbGnvO_bi+oC6_Q@mail.gmail.com
Backpatch-through: 14
M src/backend/access/transam/slru.c
Doc: add comments about PreventInTransactionBlock/IsInTransactionBlock.
commit : 8befa05d78892c3830efb4f356e1de562e4c6cb7
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
Doc: improve tutorial section about grouped aggregates.
commit : 2e4229691c666667f5b5c751773c12b2f2f6b00b
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 14.6.
commit : 6dde6ed3efb4baaa0955f78ba5c93e9490aaa490
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Nov 2022 16:38:53 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Nov 2022 16:38:53 -0500
M configure
M configure.ac
Translation updates
commit : 9c5cbed95e3761d36c1b8cdf89cb1e1f1a8aca9a
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 7 Nov 2022 13:59:56 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 7 Nov 2022 13:59:56 +0100
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: a2d024d57415123f7c9c6e7a71796c7cee8cabc6
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/ru.po
M src/bin/pg_amcheck/po/ru.po
M src/bin/pg_archivecleanup/po/ru.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_checksums/po/ru.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/ja.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/fr.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_upgrade/po/ru.po
M src/bin/pg_upgrade/po/uk.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/ru.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/ru.po
M src/interfaces/libpq/po/uk.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
Release notes for 15.1, 14.6, 13.9, 12.13, 11.18, 10.23.
commit : e527cb8cecc70c3289b8ee1b3d62bc3631bfc8d5
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-14.sgml
Correct error message for row-level triggers with transition tables on partitioned tables.
commit : 1699125ca218d4a035b794eef7c7b8872d10f527
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 4 Nov 2022 19:15:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 4 Nov 2022 19:15:03 +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 : 18865f4df9ca2369f42f98d53fc0e82e38b8a41d
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 : 2489c38cdc58bdd2f181651e741440bb6b83e80b
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 : eeb5461e76ae3df40e2443c087ab94925d767434
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 : 058c7b5dd4cc6d8f3561f843fe0f1a7839e2b26d
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 : a5b7821fc908b50ace1cdc3b972da08a265a81bd
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 : 2896aa98ef569d99ea5b27cd6e7a2a789c14fd0a
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 2 Nov 2022 18:15:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 2 Nov 2022 18:15:03 +0900
M src/backend/executor/nodeModifyTable.c
Update time zone data files to tzdata release 2022f.
commit : 97bb80b1b65ea25fe52c289826479018d7bcc167
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 : 0f2f5645a1f347bad7bfa4b670ce9aacdb9e634d
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 : 5a30d43fa9869adc5a6f708dd0994a8a4e53d905
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 26 Oct 2022 09:41:18 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 26 Oct 2022 09:41:18 +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 : aaad8adb02ed20ebff9b60f1778d4a80d76e77c1
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 : 36fc013fabd94f159553973f55afecc6cd115d60
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 21 Oct 2022 12:33:47 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 21 Oct 2022 12:33: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 : 4fbe6096b954092abc460adaddd365d5049d40f1
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 21 Oct 2022 09:52:44 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 21 Oct 2022 09:52:44 +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 contrib/test_decoding/expected/catalog_change_snapshot.out
M contrib/test_decoding/specs/catalog_change_snapshot.spec
M src/backend/replication/logical/snapbuild.c
Doc: fix outdated wording about parallel seq scans
commit : f892150076dbee167ecd850d3628443d0fb34d82
author : David Rowley <drowley@postgresql.org>
date : Fri, 21 Oct 2022 09:30:27 +1300
committer: David Rowley <drowley@postgresql.org>
date : Fri, 21 Oct 2022 09:30:27 +1300
56788d215 adjusted the parallel seq scan code so that instead of handing
out a single block at a time to parallel workers, it now hands out ranges
of blocks.
Here we update the documentation which still claimed that workers received
just 1 block at a time.
Reported-by: Zhang Mingli
Discussion: https://postgr.es/m/17c99615-2c3b-4e4e-9d0b-424a66a7bccd@Spark
Backpatch-through: 14, where 56788d215 was added.
M doc/src/sgml/parallel.sgml
Fix assertion failures while processing NEW_CID record in logical decoding.
commit : a592ed923e67871749233dcd7106a64936a971cf
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 20 Oct 2022 09:34:18 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 20 Oct 2022 09:34:18 +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 : d033f8f8bea9c7b5c4ae43a95b569ceccdaddd7a
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 19 Oct 2022 22:32:14 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 19 Oct 2022 22:32:14 +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.ac
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 : 51683feb97c1cd324617837bda727b19989c7b53
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 : b661aea772e1fd06064ee9473c2431081a4436fe
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 : 2f26cec4884366cc23737c5a9b7797935057ce38
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 : 8c611602bd356cbb47c3ebe8614f958391ec92a8
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
Fix EXPLAIN of SEARCH BREADTH FIRST with a constant initial value.
commit : 8122160ffb68acb0db740f4f6456fdaaaa577d90
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Oct 2022 19:18:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Oct 2022 19:18:08 -0400
If the non-recursive term of a SEARCH BREADTH FIRST recursive
query has only constants in its target list, the planner will
fold the starting RowExpr added by rewrite into a simple Const
of type RECORD. The executor doesn't have any problem with
that --- but EXPLAIN VERBOSE will encounter the Const as the
ultimate source of truth about what the field names of the
SET column are, and it didn't know what to do with that.
Fortunately, we can pull the identifying typmod out of the
Const, in much the same way that record_out would.
For reasons that remain a bit obscure to me, this only fails
with SEARCH BREADTH FIRST, not SEARCH DEPTH FIRST or CYCLE.
But I added regression test cases for both of those options
too, just to make sure we don't break it in future.
Per bug #17644 from Matthijs van der Vleuten. Back-patch
to v14 where these constructs were added.
Discussion: https://postgr.es/m/17644-3bd1f3036d6d7a16@postgresql.org
M src/backend/utils/adt/ruleutils.c
M src/backend/utils/fmgr/funcapi.c
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql
Rename parser token REF to REF_P to avoid a symbol conflict.
commit : 18e60712dd852f796bb31a64e8389d92be7cf9c6
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 : 6fa431d84a046603ec7c2d54ad51955487686b20
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
libpq: Reset singlerow flag correctly in pipeline mode
commit : b8af4166ff96af9c7bed1b511d0356284a8b7766
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 14 Oct 2022 19:06:26 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 14 Oct 2022 19:06:26 +0200
When a query whose results were requested in single-row mode is the last
in the queue by the time those results are being read, the single-row
flag was not being reset, because we were returning early from
pqPipelineProcessQueue. Move that stanza up so that the flag is always
reset at the end of sending that query's results.
Add a test for the situation.
Backpatch to 14.
Author: Denis Laxalde <denis.laxalde@dalibo.com>
Discussion: https://postgr.es/m/01af18c5-dacc-a8c8-07ee-aecc7650c3e8@dalibo.com
M src/interfaces/libpq/fe-exec.c
M src/test/modules/libpq_pipeline/libpq_pipeline.c
M src/test/modules/libpq_pipeline/traces/singlerow.trace
Fix typo in CREATE PUBLICATION reference page
commit : 3fe6f261f7a20cfc8e6809ae36bfe93d1f779751
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 : c6127303718cb25edab7de8bd6f76a0a1e31f3fb
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 : b10546ecf8266d2b368b98ccd491eeae5160e316
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 : 3162bd95cad3bf9ad89b9c7c8e50716cb513d46f
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 : 4f6d1cfd6b6f0707e4f4c3479261845263256f77
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 : 483d26930b4c804cecb9b074021244bd4b1c8499
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 : b93d7e6883d683ea35f4f5ea843222f47aacbaee
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 : 064e1c879dd28255202e94fdf766f4a98f916858
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
Update comment in ExecInsert() regarding batch insertion.
commit : fc9eb3f0c382dee11099ff400ff29f4b0132f16b
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 29 Sep 2022 16:55:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 29 Sep 2022 16:55:03 +0900
Remove the stale text that is a leftover from an earlier version of the
patch to add support for batch insertion, and adjust the wording in the
remaining text.
Back-patch to v14 where batch insertion came in.
Review and wording adjustment by Tom Lane.
Discussion: https://postgr.es/m/CAPmGK14goatHPHQv2Aeu_UTKqZ%2BBO%2BP%2Bzd3HKv5D%2BdyyfWKDSw%40mail.gmail.com
M src/backend/executor/nodeModifyTable.c
doc: clarify internal behavior of RECURSIVE CTE queries
commit : 81c094bd93763f76190c2a78e13cae03e15b7432
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 : bbdc1d2334e63f761e4baf37ca3243f66f56f6be
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 : f1e7f25b5aef2f3957aa4dbc5eda874871f693e0
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 : 9923764614a0a4e0e23f3455794d9c2ac0b1635d
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 : f2094c78b8015b79c922c3424e0bb27be66d455b
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
Stop using PQsendQuery in libpq_pipeline
commit : 1c03166352c3fd94dd131938e42f2a182fcf4067
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 23 Sep 2022 18:11:48 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 23 Sep 2022 18:11:48 +0200
The "emulation" I wrote for PQsendQuery in pipeline mode to use extended
query protocol, in commit acb7e4eb6b1c, is problematic. Due to numerous
bugs we'll soon remove it. As a first step and for all branches back to
14, stop using PQsendQuery in libpq_pipeline. Also remove a few test
lines that will no longer be relevant.
Backpatch to 14.
Discussion: https://postgr.es/m/CA+mi_8ZGSQNmW6-mk_iSR4JZB_LJ4ww3suOF+1vGNs3MrLsv4g@mail.gmail.com
M src/test/modules/libpq_pipeline/libpq_pipeline.c
M src/test/modules/libpq_pipeline/traces/pipeline_abort.trace
M src/test/modules/libpq_pipeline/traces/pipeline_idle.trace
Fix race condition where heap_delete() fails to pin VM page.
commit : 21934612d86a1e0c83c2774b776a022b9a5a90bd
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 : e4514aafad0b134e67d7d0cf1612fb5c76fc8fec
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 22 Sep 2022 15:55:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 22 Sep 2022 15:55:03 +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/copyfrom.c
docs: Fix snapshot name in SET TRANSACTION docs.
commit : be032619d4b16e74025d04e027b587d6e11e7cbd
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 : 88c947cb52615e073503f92e12d942cca5609a3c
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
Disable -Wdeprecated-non-prototype in the back branches.
commit : dcd7dbed50085eed92ff9733dca54e0fe5518c78
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.ac
Suppress variable-set-but-not-used warnings from clang 15.
commit : 2e124d857a64a91d2b70afdbed6156d753089771
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
doc: Fix parameter name for pg_create_logical_replication_slot()
commit : 382cc68007784623e365ec033468ec69535afbaf
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Sep 2022 19:28:47 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Sep 2022 19:28:47 +0900
The parameter controlling if two-phase transactions can be decoded was
named "two_phase" in the documentation while its procedure defines
"twophase".
Author: Florin Irion
Discussion: https://postgr.es/m/5eeabd10-1aff-ea61-f92d-9fa0d9a7e207@gmail.com
Backpatch-through: 14
M doc/src/sgml/func.sgml
Fix incorrect variable types for origin IDs in decode.c
commit : e68fc64fd7f38927720d729c667906d209ebc09f
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Sep 2022 18:13:46 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Sep 2022 18:13:46 +0900
These variables used XLogRecPtr instead of RepOriginId.
Author: Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoBm-vNyBSXGp4bmJGvhr=S-EGc5q1dtV70cFTcJvLhC=Q@mail.gmail.com
Backpatch-through: 14
M src/backend/replication/logical/decode.c
Future-proof the recursion inside ExecShutdownNode().
commit : 7394c763bc72db90cbca0fca8a17f96cc2bcc6f7
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 : 44933010ceb3ac06d4c01b559aafed4bef16c45d
author : Peter Geoghegan <pg@bowt.ie>
date : Sat, 17 Sep 2022 16:54:14 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Sat, 17 Sep 2022 16:54:14 -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 : b4b4b817da5a6293b17109f5a2d61f2e1ab8cf11
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/preadv.c
M src/port/pwrite.c
M src/port/pwritev.c
Improve plpgsql's ability to handle arguments declared as RECORD.
commit : 56d45fdab7b12cd0c767a8c1e7ab6c04390a32d8
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
Detect format-string mistakes in the libpq_pipeline test module.
commit : bff7bc6cb785191041aa7530febdbb5cfe6eaf06
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Sep 2022 17:17:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Sep 2022 17:17:53 -0400
I happened to notice that libpq_pipeline's private implementation
of pg_fatal lacked any pg_attribute_printf decoration. Indeed,
adding that turned up a mistake! We'd likely never have noticed
because the error exits in this code are unlikely to get hit,
but still, it's a bug.
We're so used to having the compiler check this stuff for us that
a printf-like function without pg_attribute_printf is a land mine.
I wonder if there is a way to detect such omissions.
Back-patch to v14 where this code came in.
M src/test/modules/libpq_pipeline/libpq_pipeline.c
postgres_fdw: Avoid 'variable not found in subplan target list' error.
commit : b53d104ae3b9cb0acfc6bb429261005bd07d3b3e
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 14 Sep 2022 18:45:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 14 Sep 2022 18:45:03 +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 : 4b529f4697f3cb59e1a225a741f14a1afb6bccd5
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 14 Sep 2022 14:52:28 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 14 Sep 2022 14:52:28 +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 : b7f37af7c195519a041fcc6084cff95dc5e4a76f
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
Don't reference out-of-bounds array elements in brin_minmax_multi.c
commit : c2aa5d01e3e33776f77e68a60ca5b60b58c5c674
author : David Rowley <drowley@postgresql.org>
date : Tue, 13 Sep 2022 11:05:13 +1200
committer: David Rowley <drowley@postgresql.org>
date : Tue, 13 Sep 2022 11:05:13 +1200
The primary fix here is to fix has_matching_range() so it does not
reference ranges->values[-1] when nranges == 0. Similar problems existed
in AssertCheckRanges() too. It does not look like any of these problems
could lead to a crash as the array in question is at the end of the Ranges
struct, and values[-1] is memory that belongs to other fields in the
struct. However, let's get rid of these rather unsafe coding practices.
In passing, I (David) adjusted some comments to try to make it more clear
what some of the fields are for in the Ranges struct. I had to study the
code to find out what nsorted was for as I couldn't tell from the
comments.
Author: Ranier Vilela
Discussion: https://postgr.es/m/CAEudQAqJQzPitufX-jR=YUbJafpCDAKUnwgdbX_MzSc93wuvdw@mail.gmail.com
Backpatch-through: 14, where multi-range brin was added.
M src/backend/access/brin/brin_minmax_multi.c
doc: Fix link to FreeBSD documentation project
commit : 293a6ac4b9898febe1cf9a4614facf6128be5d77
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 : 13b8a1c19626d425176b1e00a8104db1e339aaf3
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 : be0b0528cb64d49750fcb632faa2cfcd8d920be2
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 : e55ccb3b179cbfc5b436339cf1a71d21a73c79dc
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 : 640c20d6266ddc89e7969c697681d3f869f92dfb
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
Doc: clarify partitioned table limitations
commit : a254545a54a2e14ec6f41b8190d6c6713a85a18a
author : David Rowley <drowley@postgresql.org>
date : Mon, 5 Sep 2022 18:44:11 +1200
committer: David Rowley <drowley@postgresql.org>
date : Mon, 5 Sep 2022 18:44:11 +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 : bc73bd26f17f236368a0a3434e0c632d332803ca
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 3 Sep 2022 20:57:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 3 Sep 2022 20:57:30 +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 : 413074273918e223a496e0f5348c3b74c620b211
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 : 3eef32c58b438e08071acb22580162976bce680b
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
Doc: Update struct Trigger definition.
commit : 5527b79cc04a6aa3aab885d3bcd7162b4c620b1c
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 2 Sep 2022 16:45:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 2 Sep 2022 16:45:03 +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 : 6ec89610925448b1e7e9377afa73e158b291693c
author : David Rowley <drowley@postgresql.org>
date : Thu, 1 Sep 2022 19:22:35 +1200
committer: David Rowley <drowley@postgresql.org>
date : Thu, 1 Sep 2022 19:22:35 +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 : 8f32ac5a16197f1ee89c6b20be9ea209dc5da5ee
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 : 6fac58814c5d9fb75ac67d2bcf7732748d5634f2
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 : d11a53a8e0a77c95c47e6f2514c1ba70c18d60e0
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 : 9d8f19201a6e6b53590080b892b41f6cca6eec26
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 : d514d77ac3e36935803f2101124a1af2b57d4bf1
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 : b566f320c81878af248da0dda8f30b8327719692
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 : 4eab0181a0e1a72d4a3dd524210c3384bd6396e9
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 : 92557ac314e52c248d0a864c5e4b6088cddd8687
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 : 086ec88cda3f408b3720e352a69d41d54f97adf6
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 19:28:42 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2022 19:28:42 -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 : c1f54eac3ab67e70f507cd82d4057e4abb070111
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 : feec1b2d5af4bbac9106065f5b9f55413084a543
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 : e969f1ae2b01d7b69371332b839fa16e3b54e56d
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 : 464db46760d2a89e1933038330f1d84210115886
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 : 0e54a5e27494dd4184632aadb26a070e85fb8587
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 : 7f5dd42a40fba039543c66333714d51a469d8945
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
Use correct connection for cancellation in frontend's parallel slots
commit : aeec3534ccf3fa4a207694955b4078a9a9dafc8f
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 27 Aug 2022 15:22:11 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 27 Aug 2022 15:22:11 +0900
While waiting for slots to become available in wait_on_slots() in
parallel_slot.c, the cancellation always relied on the first connection
in the set to do the job. This could cause problems when this slot's
socket is gone as PQgetCancel() would return NULL in this case. Rather
than always using the first connection, this changes the logic to use
the first valid connection for the cancellation.
Author: Ranier Vilela
Reviewed-by: Justin Pryzby
Discussion: https://postgr.es/m/CAEudQAokk1h_pUwGXsYS4oVOuf35s1O2o3TXGHpV8=AWikvgHA@mail.gmail.com
Backpatch-through: 14
M src/fe_utils/parallel_slot.c
Fix typo in comment.
commit : 28d351c9ff2afe5cc18ef64779c02c49c76896fb
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 26 Aug 2022 16:55:02 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 26 Aug 2022 16:55:02 +0900
M src/backend/commands/copyfromparse.c
Defend against stack overrun in a few more places.
commit : 444ec169a7def141f9520c1111a31c8a5dda22ce
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 : 04f1013be084a12a251c7087b06664d0918755e6
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 : eb0097c6f3eeb559e33369066be7279f540d05db
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 : 6d05d575bec5ef9a05f8d62f1c872b71dde32a01
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 23 Aug 2022 09:24:51 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 23 Aug 2022 09:24:51 +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 : 3bfea5cbba983d35506d29563952fbadb782ef52
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 assert in logicalmsg_desc
commit : 239c3ee41be3b7c621c446344d09e3affeb8cd59
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 16 Aug 2022 23:52:10 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 16 Aug 2022 23:52:10 +0200
The assert, introduced by 9f1cf97bb5, is intended to check if the prefix
is terminated by a \0 byte, but it has two flaws. Firstly, prefix_size
includes the \0 byte, so prefix[prefix_size] points to the byte after
the null byte. Secondly, the check ensures the byte is not equal \0,
while it should be checking the opposite.
Backpatch-through: 14
Discussion: https://postgr.es/m/b99b6101-2f14-3796-3dfa-4a6cd7d4326d@enterprisedb.com
M src/backend/access/rmgrdesc/logicalmsgdesc.c
doc: Remove reference to tty libpq connstring param
commit : 1d968b87047708eae1d0eef27860668ec318a3ee
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Tue, 16 Aug 2022 22:54:43 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Tue, 16 Aug 2022 22:54:43 +0200
The tty connection string parameter was removed in commit 14d9b3760
but the reference to it in the docs was mistakenly kept. Fix by
removing it from the libpq documentation. Backpatch through v14
where the parameter was removed.
Author: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com>
Discussion: https://postgr.es/m/DM4PR84MB173433216FCC2A3961879000EE6B9@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
Backpatch-through: 14
M doc/src/sgml/libpq.sgml
Fix replica identity check for a partitioned table.
commit : 02f8d68af256c34cfac774ae46b2d4a465d35276
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 16 Aug 2022 14:51:42 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 16 Aug 2022 14:51:42 +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 : a1a5e6d95cc9fabbd4e0209161662aa45220c4b1
author : Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 16 Aug 2022 09:27:34 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 16 Aug 2022 09:27:34 +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 : d63a69157d189bf3d56eb5ad37fa67d0134bfb31
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 : 63b64d8270691894a9a8f2d4e929e7780020edb8
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 15 Aug 2022 13:37:38 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 15 Aug 2022 13:37:38 +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 : 06602372b36df2b36e4db5ac30504dad878ea254
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 : 1dfc9193af7ff3cde963aa153e21fadbfebe030a
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 : 496ab1d6c8d853899595e986f04cd70c4b13dac4
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 : 2db574a2184e5e6ae289e48079e8523c9cbdc8c4
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 : 08c5c6d2833bfae8a27ed7ab3f66513b735321bb
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 : 88b54b07916c58c7cd20cc0998dc2c62c060a1f7
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 : 675a368a35a1ae4aa2c54fbd2a8310e3939d73b8
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 15:05:13 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 15:05:13 -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 : 9039e34e7ed26710e49b4c43d8859387cf4f4faf
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 : ec98eac9873bd50d75fc51a440848d07ba158d8f
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 : e6f7892914ab70b40a2ffa71887e3bdcfa668988
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 : ff48a0c80ec8dc47ba59161b43058ddcdfbe5b09
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 : a8fade6cb5ecadca939b2ced770d809631fddd89
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 10:30:01 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 10:30:01 -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 : ec3530f4597540cec9d6ccdb2290899822581128
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 09:06:48 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 12 Aug 2022 09:06:48 -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 : 3f4069ca2c3efdc5d945fb7a4a5b4a1ecd176719
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 : e082ef9c4282d4dd9c15585ef7a4da30db1289d5
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 12 Aug 2022 11:16:35 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 12 Aug 2022 11:16:35 +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/014_binary.pl
M src/test/subscription/t/015_stream.pl
M src/test/subscription/t/016_stream_subxact.pl
M src/test/subscription/t/017_stream_ddl.pl
M src/test/subscription/t/018_stream_subxact_abort.pl
M src/test/subscription/t/019_stream_subxact_ddl_abort.pl
M src/test/subscription/t/021_alter_sub_pub.pl
M src/test/subscription/t/100_bugs.pl
Fix catalog lookup with the wrong snapshot during logical decoding.
commit : 68dcce247f1a13318613a0e27782b2ca21a4ceb7
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 11 Aug 2022 09:45:04 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 11 Aug 2022 09:45:04 +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 : 95bfadd4e83c17f1a31ab97eb2aba44a38c36324
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 14.5.
commit : 278273ccbad27a8834dfdf11895da9cd91de4114
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Aug 2022 16:44:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Aug 2022 16:44:29 -0400
M configure
M configure.ac
Stabilize output of new regression test.
commit : c0d5d52a780fb575d8f93d0b1a8ef8cb43851a84
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 : ea2917ca905b7a669cc9d90c3b0e4539667a15a4
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-14.sgml
In extensions, don't replace objects not belonging to the extension.
commit : 5721da7e41e7a280587bda29cd1674c7da3317f8
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 : 9a8df3307088f2f401cdad06df9351154819de45
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: 20d70fc4a9763d5d31afc422be0be0feb0fb0363
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/uk.po
M src/bin/pg_amcheck/po/es.po
M src/bin/pg_amcheck/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/uk.po
M src/bin/pg_checksums/po/es.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/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/uk.po
M src/bin/pg_rewind/po/es.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/uk.po
M src/bin/pg_test_timing/po/es.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/fr.po
M src/bin/pg_upgrade/po/ja.po
M src/bin/pg_upgrade/po/sv.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/uk.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/uk.po
M src/interfaces/ecpg/ecpglib/po/es.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/de.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/sv.po
M src/interfaces/libpq/po/uk.po
M src/pl/plperl/po/es.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/uk.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/uk.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/uk.po
Release notes for 14.5, 13.8, 12.12, 11.17, 10.22.
commit : 3526a8f7b4242ad5a80fbdf27636625e7b192be6
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-14.sgml
Remove unportable use of timezone in recent test
commit : f4beef1c2d66cdbfd036117a8cbf9a703d83d33e
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 : 9d5c96d9be6476c4a7a3fa227e6e20748f1d827f
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
First-draft release notes for 14.5.
commit : aab05919a685449826db986a921c1d8632d673e0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2022 17:38:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2022 17:38:53 -0400
As usual, the release notes for older branches will be made by cutting
these down, but put them up for community review first.
Due to the out-of-cycle release of 14.4, there are a number of commits
that appeared in 14.4 that are not yet shipped in the earlier branches.
This draft repeats those release note entries for convenience in
preparing the older-branch notes later. They'll be stripped out of
the 14.5 section after that's done.
M doc/src/sgml/release-14.sgml
Partially undo commit 94da73281.
commit : b9243cadad55e296e83839fb96457f64dcaaeb25
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 handling of bare boolean expressions in mcv_get_match_bitmap.
commit : 3fe2fc6bbdb251c78a88cdd41e400014be76f80e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2022 15:00:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2022 15:00:03 -0400
Since v14, the extended stats machinery will try to estimate for
otherwise-unsupported boolean expressions if they match an expression
available from an extended stats object. mcv.c did not get the memo
about this, and would spit up with "unknown clause type". Fortunately
the case is easy to handle, since we can expect the expression yields
boolean.
While here, replace some not-terribly-on-point assertions with
simpler runtime tests for lookup failure. That seems appropriate
so that we get an elog not a crash if we somehow get to the new
it-should-be-a-bool-expression code with a subexpression that
doesn't match any stats column.
Per report from Danny Shemesh. Thanks to Justin Pryzby for
preliminary investigation.
Discussion: https://postgr.es/m/CAFZC=QqD6=27wQPOW1pbRa98KPyuyn+7cL_Ay_Ck-roZV84vHg@mail.gmail.com
M src/backend/statistics/mcv.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Fix non-bulletproof ScalarArrayOpExpr code for extended statistics.
commit : ea6c916962c4fc87c3d26d938e0149d4c91f2ca0
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 : fff3f3333fdc34d9f412fc8c87bef47ce4007ce9
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
M .git-blame-ignore-revs
Fix incorrect permissions-checking code for extended statistics.
commit : 7c6ce0475a344d1f35b500898768530d0c02030a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2022 12:46:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2022 12:46:34 -0400
Commit a4d75c86b improved the extended-stats logic to allow extended
stats to be collected on expressions not just bare Vars. To apply
such stats, we first verify that the user has permissions to read all
columns used in the stats. (If not, the query will likely fail at
runtime, but the planner ought not do so.) That had to get extended
to check permissions of columns appearing within such expressions,
but the code for that was completely wrong: it applied pull_varattnos
to the wrong pointer, leading to "unrecognized node type" failures.
Furthermore, although you couldn't get to this because of that bug,
it failed to account for the attnum offset applied by pull_varattnos.
This escaped recognition so far because the code in question is not
reached when the user has whole-table SELECT privilege (which is the
common case), and because only subexpressions not specially handled
by statext_is_compatible_clause_internal() are at risk.
I think a large part of the reason for this bug is under-documentation
of what statext_is_compatible_clause() is doing and what its arguments
are, so do some work on the comments to try to improve that.
Per bug #17570 from Alexander Kozhemyakin. Patch by Richard Guo;
comments and other cosmetic improvements by me. (Thanks also to
Japin Li for diagnosis.) Back-patch to v14 where the bug came in.
Discussion: https://postgr.es/m/17570-f2f2e0f4bccf0965@postgresql.org
M src/backend/statistics/extended_stats.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
BRIN: mask BRIN_EVACUATE_PAGE for WAL consistency checking
commit : 541f41d4fa783ce213f15d4f5faaca5bb7a50559
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 : 8ad6c5dbbe5a234c55c6663020db297251756006
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 : 6d9481cd05d2a0d4152c02c5d48b7f7eb7b90a49
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
postgres_fdw: Disable batch insertion when there are WCO constraints.
commit : 4a9bc2e0f5226d29e7e11c9611b8649a4aa74a4b
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 5 Aug 2022 17:15:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 5 Aug 2022 17:15:03 +0900
When inserting a view referencing a foreign table that has WITH CHECK
OPTION constraints, in single-insert mode postgres_fdw retrieves the
data that was actually inserted on the remote side so that the WITH
CHECK OPTION constraints are enforced with the data locally, but in
batch-insert mode it cannot currently retrieve the data (except for the
row first inserted through the view), resulting in enforcing the WITH
CHECK OPTION constraints with the data passed from the core (except for
the first-inserted row), which led to incorrect results when inserting
into a view referencing a foreign table in which a remote BEFORE ROW
INSERT trigger changes the rows inserted through the view so that they
violate the view's WITH CHECK OPTION constraint. Also, the query
inserting into the view caused an assertion failure in assert-enabled
builds.
Fix these by disabling batch insertion when inserting into such a view.
Back-patch to v14 where batch insertion was added.
Discussion: https://postgr.es/m/CAPmGK17LpbTZs4m4a_6THP54UBeK9fHvX8aVVA%2BC6yEZDZwQcg%40mail.gmail.com
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
Fix ENABLE/DISABLE TRIGGER to handle recursion correctly
commit : 731d514ae58ff4b5c81729881d350c6f89c4e488
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 : efba7a63ffbe59790b88e3af459dfd81c742b90f
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 : 1a9ac84923b8530ca18d497b3ccc40965c01b66b
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 assorted doc typos
commit : 120e159b7d93fa36b94ded8a51fe4e619e1261ca
author : John Naylor <john.naylor@postgresql.org>
date : Thu, 4 Aug 2022 15:59:32 +0700
committer: John Naylor <john.naylor@postgresql.org>
date : Thu, 4 Aug 2022 15:59:32 +0700
Erik Rijkers and Justin Pryzby
Backpatch to v14
Discussion: https://www.postgresql.org/message-id/b79bfeff-d0e3-29a3-2576-0e325848dede%40xs4all.nl
M doc/src/sgml/brin.sgml
M doc/src/sgml/ref/drop_extension.sgml
Clarify DROP EXTENSION docs regarding explicitly dependent routines
commit : d107e73fa8b5ba874a4b29be73e743652c32efd2
author : John Naylor <john.naylor@postgresql.org>
date : Thu, 4 Aug 2022 15:29:25 +0700
committer: John Naylor <john.naylor@postgresql.org>
date : Thu, 4 Aug 2022 15:29:25 +0700
Per suggestion from Robert Haas
Backpatch to v14
Discussion: https://www.postgresql.org/message-id/CA%2BTgmoZ1QvHquYHLkMy1oHKqz4-E7QQctj6e0ocq_GP1B5%2B9bA%40mail.gmail.com
M doc/src/sgml/ref/drop_extension.sgml
Fix incorrect tests for SRFs in relation_can_be_sorted_early().
commit : 445b9020c97f3e1ff63534efeec5a280e33d2495
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 : 8eaa4d0f3dbe2022f683cb8c90beeafbb43232fa
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 : 17fd203b414e9a1d649fb22ab11afd8355947476
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 : d947a8bd5606af4333076724d20b4cb87d386c30
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 : 523926dea97f360f1f785853eea49e4dc4a6e1e9
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 1 Aug 2022 16:39:27 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 1 Aug 2022 16:39:27 +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 trim_array() for zero-dimensional array argument.
commit : e71d4254f710bef53fa40d0b49b5af9bad10ce40
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 31 Jul 2022 13:43:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 31 Jul 2022 13:43:17 -0400
The code tried to access ARR_DIMS(v)[0] and ARR_LBOUND(v)[0]
whether or not those values exist. This made the range check
on the "n" argument unstable --- it might or might not fail, and
if it did it would report garbage for the allowed upper limit.
These bogus accesses would probably annoy Valgrind, and if you
were very unlucky even lead to SIGSEGV.
Report and fix by Martin Kalcher. Back-patch to v14 where this
function was added.
Discussion: https://postgr.es/m/baaeb413-b8a8-4656-5757-ef347e5ec11f@aboutsource.net
M src/backend/utils/adt/arrayfuncs.c
M src/test/regress/expected/arrays.out
M src/test/regress/sql/arrays.sql
Fix new recovery test for log_error_verbosity=verbose case
commit : e90c4fc881e2c836b4d4fb9fae03310f9c0d8597
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 : 8df167baa7c76685cde43611df7026b5ad2e708e
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 : 4d8d85740c0228b04a10818587b70f4ae3a2beba
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 : a3aacb7cbfc74fc20e8681cba99e2db84c8dd980
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
Fix get_dirent_type() for symlinks on MinGW/MSYS.
commit : 5ad478c9d95657948fd818ac7e97a28eea3c3433
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 28 Jul 2022 14:13:37 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 28 Jul 2022 14:13:37 +1200
On Windows with MSVC, get_dirent_type() was recently made to return
DT_LNK for junction points by commit 9d3444dc, which fixed some
defective dirent.c code.
On Windows with Cygwin, get_dirent_type() already worked for symlinks,
as it does on POSIX systems, because Cygwin has its own fake symlinks
that behave like POSIX (on closer inspection, Cygwin's dirent has the
BSD d_type extension but it's probably always DT_UNKNOWN, so we fall
back to lstat(), which understands Cygwin symlinks with S_ISLNK()).
On Windows with MinGW/MSYS, we need extra code, because the MinGW
runtime has its own readdir() without d_type, and the lstat()-based
fallback has no knowledge of our convention for treating junctions as
symlinks.
Back-patch to 14, where get_dirent_type() landed.
Reported-by: Andrew Dunstan <andrew@dunslane.net>
Discussion: https://postgr.es/m/b9ddf605-6b36-f90d-7c30-7b3e95c46276%40dunslane.net
M src/common/file_utils.c
Allow "in place" tablespaces.
commit : 961cab0a5a90d449a64a71912b324d7e7548619b
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 : 3e1297a63f760b02ea8d951f6b270c9c843083ae
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
Fix ReadRecentBuffer for local buffers.
commit : 3f968b9415045c4f8ae3cd56b5b4a83d1aa27db8
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 25 Jul 2022 08:48:38 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 25 Jul 2022 08:48:38 +0300
It incorrectly used GetBufferDescriptor instead of
GetLocalBufferDescriptor, causing it to not find the correct buffer in
most cases, and performing an out-of-bounds memory read in the corner
case that temp_buffers > shared_buffers.
It also bumped the usage-count on the buffer, even if it was
previously pinned. That won't lead to crashes or incorrect results,
but it's different from what the shared-buffer case does, and
different from the usual code in LocalBufferAlloc. Fix that too, and
make the code ordering match LocalBufferAlloc() more closely, so that
it's easier to verify that it's doing the same thing.
Currently, ReadRecentBuffer() is only used with non-temp relations, in
WAL redo, so the broken code is currently dead code. However, it could
be used by extensions.
Backpatch-through: 14
Discussion: https://www.postgresql.org/message-id/2d74b46f-27c9-fb31-7f99-327a87184cc0%40iki.fi
Reviewed-by: Thomas Munro, Zhang Mingli, Richard Guo
M src/backend/storage/buffer/bufmgr.c
Doc: improve documentation about random().
commit : 31d5354cb148c6aa90014f62d3a4752adeebd51a
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
Fix get_dirent_type() for Windows junction points.
commit : fee0165fc1cfaf4ac0052c4554810e46c02dd70c
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 22 Jul 2022 16:57:12 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 22 Jul 2022 16:57:12 +1200
Commit 87e6ed7c8 added code that intended to report Windows "junction
points" as DT_LNK (the same way we report symlinks on Unix). Windows
junction points are *also* directories according to the Windows
attributes API, and we were reporting them as as DT_DIR. Change the
order we check the attribute flags, to prioritize DT_LNK.
If at some point we start using Windows' recently added real symlinks
and need to distinguish them from junction points, we may need to
rethink this, but for now this continues the tradition of wrapper
functions that treat junction points as symlinks.
Back-patch to 14, where get_dirent_type() landed.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/CA%2BhUKGLzLK4PUPx0_AwXEWXOYAejU%3D7XpxnYE55Y%2Be7hB2N3FA%40mail.gmail.com
Discussion: https://postgr.es/m/20220721111751.x7hod2xgrd76xr5c%40alvherre.pgsql
M src/port/dirent.c
postgres_fdw: Fix bug in checking of return value of PQsendQuery().
commit : 169d50ba34a91a1c3e2535b8ef49480bad4b9867
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 21 Jul 2022 22:52:50 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 21 Jul 2022 22:52:50 +0900
When postgres_fdw begins an asynchronous data fetch, it submits FETCH query
by using PQsendQuery(). If PQsendQuery() fails and returns 0, postgres_fdw
should report an error. But, previously, postgres_fdw reported an error
only when the return value is less than 0, though PQsendQuery() never return
the values other than 0 and 1. Therefore postgres_fdw could not handle
the failure to send FETCH query in an asynchronous data fetch.
This commit fixes postgres_fdw so that it reports an error
when PQsendQuery() returns 0.
Back-patch to v14 where asynchronous execution was supported in postgres_fdw.
Author: Fujii Masao
Reviewed-by: Japin Li, Tom Lane
Discussion: https://postgr.es/m/b187a7cf-d4e3-5a32-4d01-8383677797f3@oss.nttdata.com
M contrib/postgres_fdw/postgres_fdw.c
doc: use wording "restore" instead of "reload" of dumps
commit : e613466e46c86d6c64bac062b35ef5d0ca539d19
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 : 21640e986518ab7d15b5a811cf2c5064af244249
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 : da9a28fd5563261354d648258b1824b3f35dde5c
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 : be2e842c8a79d98a3fa03eeaf9329bf1f51a9704
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 : 2aedf25eb4d0a89c38dbbad8e5bbda237838292f
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 : 8657946d375f4831b026d7c28016b27acdd2c246
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
604651880c71c5106a72529b9ce29eaad0cfab27.
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
pg_upgrade: Adjust quoting style in message to match guidelines
commit : 9293589d96756f921f54793c4586c6bd61f94e4f
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 18 Jul 2022 14:53:00 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 18 Jul 2022 14:53:00 +0200
M src/bin/pg_upgrade/check.c
Fix omissions in support for the "regcollation" type.
commit : bb30410b9f4cae1ec74f120833b74ecc0b1de7d2
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 : 810bcbd383ab615a24ea972db0e1157572f3a12c
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 : c412c60b91ac01d07774026991b949c1b43fa5e4
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
Clarify that pg_dump takes ACCESS SHARE lock
commit : 2ebb8416cc4c1b8f73481335c2c6ce07286bc938
author : John Naylor <john.naylor@postgresql.org>
date : Fri, 1 Jul 2022 11:41:36 +0700
committer: John Naylor <john.naylor@postgresql.org>
date : Fri, 1 Jul 2022 11:41:36 +0700
Add link to the description of lock levels to avoid confusing "shared locks"
with SHARE locks.
Florin Irion
Reviewed-by: Álvaro Herrera, Tom Lane, and Nathan Bossart
Discussion: https://www.postgresql.org/message-id/flat/d0f30cc2-3c76-1d43-f291-7c4b2872d653@gmail.com
This is a backpatch of 4e2e8d71f, applied through version 14
M doc/src/sgml/ref/pg_dump.sgml
docs: make monitoring "phases" table titles consistent
commit : e1d5ac3118be2c8f93a7b9c8813027f7a7f8d049
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 : 2fc2d805e9c7acd554689782e854cd713faf9575
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 : 0d8db8cf853ceb34c5be1e398fc566b0521bb24e
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 : 8e97474834e4247886ecb11ffc39d65239eddfe2
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 : 8f253ba251b86d6792cb81093e5d84457bc9790a
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 : 3bfe26bd4ce11ee5bd2a2f240ee24e220f3f8635
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 : 4996786a90aa195025e2ee1fccb9d478740108a6
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 : 6396ab3d14278746951ea78fb8207534a8825a7e
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 : 8383645592de522e9791ba84ddde23f3105366b5
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 : 2019e6ecfa26b11e2191a7a1ab41cea4f3ef1544
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
Plug memory leak
commit : 9e038d6907b3d6cf5854eb36bf150db90bec60a0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 13 Jul 2022 12:10:03 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 13 Jul 2022 12:10:03 +0200
Commit 054325c5eeb3 created a memory leak in PQsendQueryInternal in case
an error occurs while sending the message. Repair.
Backpatch to 14, like that commit. Reported by Coverity.
M src/interfaces/libpq/fe-exec.c
Invent qsort_interruptible().
commit : af72b0889441e5ece199f782511d84d72fa6b88c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Jul 2022 16:30:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Jul 2022 16:30:36 -0400
Justin Pryzby reported that some scenarios could cause gathering
of extended statistics to spend many seconds in an un-cancelable
qsort() operation. To fix, invent qsort_interruptible(), which is
just like qsort_arg() except that it will also do CHECK_FOR_INTERRUPTS
every so often. This bloats the backend by a couple of kB, which
seems like a good investment. (We considered just enabling
CHECK_FOR_INTERRUPTS in the existing qsort and qsort_arg functions,
but there are some callers for which that'd demonstrably be unsafe.
Opt-in seems like a better way.)
For now, just apply qsort_interruptible() in statistics collection.
There's probably more places where it could be useful, but we can
always change other call sites as we find problems.
Back-patch to v14. Before that we didn't have extended stats on
expressions, so that the problem was less severe. Also, this patch
depends on the sort_template infrastructure introduced in v14.
Tom Lane and Justin Pryzby
Discussion: https://postgr.es/m/20220509000108.GQ28830@telsasoft.com
M src/backend/commands/analyze.c
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
M src/backend/statistics/mvdistinct.c
M src/backend/tsearch/ts_typanalyze.c
M src/backend/utils/adt/array_typanalyze.c
M src/backend/utils/adt/rangetypes_typanalyze.c
M src/backend/utils/sort/Makefile
A src/backend/utils/sort/qsort_interruptible.c
M src/include/port.h
Fix lock assertions in dshash.c.
commit : 5e7608e81ebb2a9e2a72ab771eba3c620c0b42a6
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
doc: Fix inconsistent quotes in some jsonb fields
commit : ec5f1fe2fca5f7b8f06aed6f3f4efbe8288c031e
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 11 Jul 2022 10:56:48 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 11 Jul 2022 10:56:48 +0900
Single quotes are not allowed in json internals, double quotes are.
Reported-by: Eric Mutta
Discussion: https://postgr.es/m/165715362165.665.3875113264927503997@wrigleys.postgresql.org
Backpatch-through: 14
M doc/src/sgml/json.sgml
Fix \watch's interaction with libedit on ^C.
commit : ab7fef0acfbd33331b4d3a000d501454fdcee8f2
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 : f1c779e2b9e48eab05ad471e4111eb17e7e6ad3a
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 8 Jul 2022 20:23:35 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 8 Jul 2022 20:23:35 -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 : 9d71664c88defe967ccdbf485c0216c0d5a301ee
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 : 8d8464445a476f0de961006d684922ada545d9a4
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 7 Jul 2022 13:08:03 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 7 Jul 2022 13:08:03 +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
Tighten pg_upgrade's new check for non-upgradable anyarray usages.
commit : 9783413cbff9f2b4893ab81e873968905a2cfbfc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 Jul 2022 18:23:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 Jul 2022 18:23:19 -0400
We only need to reject cases when the aggregate or operator is
itself declared with a polymorphic type. Per buildfarm.
Discussion: https://postgr.es/m/3383880.QJadu78ljV@vejsadalnx
M src/bin/pg_upgrade/check.c
Fix pg_upgrade to detect non-upgradable anyarray usages.
commit : 175e60a5e35e213f42ed69eeb5ab992a49ae41f4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 Jul 2022 13:06:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 Jul 2022 13:06:31 -0400
When we changed some built-in functions to use anycompatiblearray
instead of anyarray, we created a dump/restore hazard for user-defined
operators and aggregates relying on those functions: the user objects
have to be modified to change their signatures similarly. This causes
pg_upgrade to fail partway through if the source installation contains
such objects. We generally try to have pg_upgrade detect such hazards
and fail before it does anything exciting, so add logic to detect
this case too.
Back-patch to v14 where the change was made.
Justin Pryzby, reviewed by Andrey Borodin
Discussion: https://postgr.es/m/3383880.QJadu78ljV@vejsadalnx
M src/bin/pg_upgrade/check.c
libpq: Improve idle state handling in pipeline mode
commit : 7c1f426123845c8be6a3a2791dbc0ebc87a92c40
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 5 Jul 2022 14:21:20 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 5 Jul 2022 14:21:20 +0200
We were going into IDLE state too soon when executing queries via
PQsendQuery in pipeline mode, causing several scenarios to misbehave in
different ways -- most notably, as reported by Daniele Varrazzo, that a
warning message is produced by libpq:
message type 0x33 arrived from server while idle
But it is also possible, if queries are sent and results consumed not in
lockstep, for the expected mediating NULL result values from PQgetResult
to be lost (a problem which has not been reported, but which is more
serious).
Fix this by introducing two new concepts: one is a command queue element
PGQUERY_CLOSE to tell libpq to wait for the CloseComplete server
response to the Close message that is sent by PQsendQuery. Because the
application is not expecting any PGresult from this, the mechanism to
consume it is a bit hackish.
The other concept, authored by Horiguchi-san, is a PGASYNC_PIPELINE_IDLE
state for libpq's state machine to differentiate "really idle" from
merely "the idle state that occurs in between reading results from the
server for elements in the pipeline". This makes libpq not go fully
IDLE when the libpq command queue contains entries; in normal cases, we
only go IDLE once at the end of the pipeline, when the server response
to the final SYNC message is received. (However, there are corner cases
it doesn't fix, such as terminating the query sequence by
PQsendFlushRequest instead of PQpipelineSync; this sort of scenario is
what requires PGQUERY_CLOSE bit above.)
This last bit helps make the libpq state machine clearer; in particular
we can get rid of an ugly hack in pqParseInput3 to avoid considering
IDLE as such when the command queue contains entries.
A new test mode is added to libpq_pipeline.c to tickle some related
problematic cases.
Reported-by: Daniele Varrazzo <daniele.varrazzo@gmail.com>
Co-authored-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://postgr.es/m/CA+mi_8bvD0_CW3sumgwPvWdNzXY32itoG_16tDYRu_1S2gV2iw@mail.gmail.com
M src/interfaces/libpq/fe-exec.c
M src/interfaces/libpq/fe-protocol3.c
M src/interfaces/libpq/libpq-int.h
M src/test/modules/libpq_pipeline/libpq_pipeline.c
M src/test/modules/libpq_pipeline/t/001_libpq_pipeline.pl
A src/test/modules/libpq_pipeline/traces/pipeline_idle.trace
BRIN: improve documentation on summarization
commit : 0b71e43c4892bdbbf57e6ff441d9443f22d1fda3
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 : 7fd43684fc9e3f2da9c646dea04a531bd6f50cee
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 : 463a841d7407dbc96cc1c39ca99ebe9c8bdd3244
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 : 5b94e2bd4d5430f5ea4e965a32727a6006972a55
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 : fb81a93a6442e55d8c7376a01c27cb5d6c062c80
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 : e24615a0057a9932904317576cf5c4d42349b363
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 relptr's encoding of the base address.
commit : 99504ff8265eac35da5af06f4ce99196bbdc0239
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 27 Jun 2022 10:30:15 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 27 Jun 2022 10:30:15 +1200
Previously, we encoded both NULL and the first byte at the base address
as 0. That confusion led to the assertion in commit e07d4ddc, which
failed when min_dynamic_shared_memory was used. Give them distinct
encodings, by switching to 1-based offsets for non-NULL pointers. Also
improve macro hygiene in passing (missing/misplaced parentheses), and
remove open-coded access to the raw offset value from freepage.c/h.
Although e07d4ddc was back-patched to 10, the only code that actually
makes use of relptr at the base address arrived in 84b1c63a, so no need
to back-patch further than 14 for now.
Reported-by: Justin Pryzby <pryzby@telsasoft.com>
Reviewed-by: Robert Haas <robertmhaas@gmail.com>
Discussion: https://postgr.es/m/20220519193839.GT19626%40telsasoft.com
M src/backend/utils/mmgr/freepage.c
M src/include/utils/freepage.h
M src/include/utils/relptr.h
Don't trust signalfd() on illumos.
commit : e086b55381a98975348051d218cff0752c19d0f9
author : Thomas Munro <tmunro@postgresql.org>
date : Sun, 26 Jun 2022 10:40:06 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Sun, 26 Jun 2022 10:40:06 +1200
Since commit 6a2a70a02, we've used signalfd() to receive latch wakeups
when building with WAIT_USE_EPOLL (default for Linux and illumos), and
our traditional self-pipe when falling back to WAIT_USE_POLL (default
for other Unixes with neither epoll() nor kqueue()).
Unexplained hangs and kernel panics have been reported on illumos
systems, apparently linked to this use of signalfd(), leading illumos
users and build farm members to have to define WAIT_USE_POLL explicitly
as a work-around. A bug report exists at
https://www.illumos.org/issues/13700 but no fix is available yet.
Let's provide a way for illumos users to go back to self-pipes with
epoll(), like releases before 14, and choose that by default. No change
for Linux users. To help with development/debugging, macros
WAIT_USE_{EPOLL,POLL} and WAIT_USE_{SIGNALFD,SELF_PIPE} can be defined
explicitly to override the defaults.
Back-patch to 14, where we started using signalfd().
Reported-by: Japin Li <japinli@hotmail.com>
Reported-by: Olaf Bohlen <olbohlen@eenfach.de> (off-list)
Reviewed-by: Japin Li <japinli@hotmail.com>
Discussion: https://postgr.es/m/MEYP282MB1669C8D88F0997354C2313C1B6CA9%40MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
M src/backend/storage/ipc/latch.c
Fix PostgreSQL::Test aliasing for Perl v5.10.1.
commit : 4b0d21b06c6b0f3b0fec0d069759f4b82913e452
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 : ace9973867c2f17ed6191a4a3b9a46939a2df45b
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 : 20911775de4ab7ac3ecc68bd714cb3ed0fd68b6a
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 : 3238b5c330bc384441473dd2859845c27d9ade2f
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 23 Jun 2022 09:20:41 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 23 Jun 2022 09:20:41 +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 : f1e3a7075832f218a36feb04b059c7da04fb19ee
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 22 Jun 2022 16:59:54 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 22 Jun 2022 16:59:54 -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 : 1463f22d42fddc620ca29c6fa9eb7dce0e56a2fe
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 : 604651880c71c5106a72529b9ce29eaad0cfab27
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 Jun 2022 12:11:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 Jun 2022 12:11:59 -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 : f0022a77d011411d8314e1e554e182d0ab8e142e
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Jun 2022 15:30:36 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Jun 2022 15:30:36 +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 : 52d5ea9adb010d0908e8962842571cd1f6c2d66c
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Jun 2022 07:52:41 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Jun 2022 07:52:41 +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 : 0980adfd4d021e3329bf41452ce1a1210321974f
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 16 Jun 2022 08:32:10 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 16 Jun 2022 08:32:10 +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 : d457cb4e8a5e25fe16420cb91cb8450d8fca49d3
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 15 Jun 2022 09:59:52 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 15 Jun 2022 09:59:52 +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 : 7bc21ed8c8e755ef6fe41dae60c198fcc9c9ee56
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 : be35a6456901cfdf4df91697370dc5edac7e58c5
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
Stamp 14.4.
commit : 164d174bbf9a3aba719c845497863cd3c49a3ad0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Jun 2022 16:04:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Jun 2022 16:04:05 -0400
M configure
M configure.ac
Translation updates
commit : cb31fc24b7283a663d1cfc760bb655a86a48b571
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 13 Jun 2022 07:32:39 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 13 Jun 2022 07:32:39 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: e9a1d874376107ca29ff102e5fbbaee41532217a
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/sv.po
M src/bin/initdb/po/ja.po
M src/bin/pg_amcheck/po/ja.po
M src/bin/pg_archivecleanup/po/ja.po
M src/bin/pg_basebackup/po/ja.po
M src/bin/pg_checksums/po/ja.po
M src/bin/pg_config/po/ja.po
M src/bin/pg_controldata/po/ja.po
M src/bin/pg_ctl/po/ja.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/ja.po
M src/bin/pg_resetwal/po/ja.po
M src/bin/pg_rewind/po/ja.po
M src/bin/pg_test_fsync/po/ja.po
M src/bin/pg_test_timing/po/ja.po
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/ja.po
M src/bin/pg_verifybackup/po/ja.po
M src/bin/pg_waldump/po/ja.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/sv.po
M src/bin/scripts/po/ja.po
M src/interfaces/ecpg/ecpglib/po/ja.po
M src/interfaces/ecpg/preproc/po/ja.po
M src/interfaces/libpq/po/ja.po
M src/pl/plperl/po/ja.po
M src/pl/plpgsql/src/po/ja.po
M src/pl/plpython/po/ja.po
M src/pl/tcl/po/ja.po
Doc: remove a04ccf6df from release notes, now that it's reverted.
commit : 18f66a1a91bdc44dce2823faec9530dc14223234
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Jun 2022 16:38:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Jun 2022 16:38:15 -0400
Discussion: https://postgr.es/m/17504-76b68018e130415e@postgresql.org
M doc/src/sgml/release-14.sgml
Revert "Fix psql's single transaction mode on client-side errors with -c/-f switches".
commit : f25b5519c99a68324b147dad15b68b1a3bd378ad
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
First-draft release notes for 14.4.
commit : 03fa84ac7c9239a18b7953d49acedd80f6aaccee
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Jun 2022 13:47:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Jun 2022 13:47:19 -0400
M doc/src/sgml/release-14.sgml
Un-break whole-row Vars referencing domain-over-composite types.
commit : 77c1d92cbac15f3c9c02f9a5b1ef551842659de6
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 : 0ccef410e4c35fd6a742091736b6fe1997eec6d3
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 : 804a5079220d48598ce15a16f76c5d2d0df923d1
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 8 Jun 2022 14:27:42 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 8 Jun 2022 14:27:42 +0200
M src/test/perl/PostgreSQL/Test/Cluster.pm
Harden Memoization code against broken data types
commit : cbcea3b91dcd242473dfdc5464dcfb53dae2bdf4
author : David Rowley <drowley@postgresql.org>
date : Wed, 8 Jun 2022 12:39:44 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 8 Jun 2022 12:39:44 +1200
Bug #17512 highlighted that a suitably broken data type could cause the
backend to crash if either the hash function or equality function were in
someway non-deterministic based on their input values. Such a data type
could cause a crash of the backend due to some code which assumes that
we'll always find a hash table entry corresponding to an item in the
Memoize LRU list.
Here we remove the assumption that we'll always find the entry
corresponding to the given LRU list item and add run-time checks to verify
we have found the given item in the cache.
This is not a fix for bug #17512, but it will turn the crash reported by
that bug report into an internal ERROR.
Reported-by: Ales Zeleny
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/CAApHDvpxFSTwvoYWT7kmFVSZ9zLAeHb=S9vrz=RExMgSkQNWqw@mail.gmail.com
Backpatch-through: 14, where Memoize was added.
M src/backend/executor/nodeMemoize.c
Fix off-by-one loop termination condition in pg_stat_get_subscription().
commit : 5c3b5f7db6cee574488dfbb9462f0eb6090315b9
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 pg_amcheck.
commit : 32a85ee46b034be7b8bf8f31b24cf6fe3684fe7f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Jun 2022 11:26:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Jun 2022 11:26:57 -0400
An error PGresult generated by libpq itself, such as a report of
connection loss, won't have broken-down error fields.
should_processing_continue() blithely assumed that
PG_DIAG_SEVERITY_NONLOCALIZED would always be present, and would
dump core if it wasn't.
Per grepping to see if 6d157e7cb's mistake was repeated elsewhere.
M src/bin/pg_amcheck/pg_amcheck.c
Don't fail on libpq-generated error reports in ecpg_raise_backend().
commit : a5dbca460ace7e89a607d43e206973efaee0ed19
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 : a04ccf6dfb4a15b9c279154b3366f8051de8b5d1
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 6 Jun 2022 11:07:22 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 6 Jun 2022 11:07:22 +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 : c1ad8047a2c22f841e4e3df39696febeb7167e6c
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 : 2223c2a7c4403e71c2553c313e958503084077f3
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 : 18e3b197bc6a4d957a92b3540b7afcc07a9e7f29
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 2 Jun 2022 18:00:02 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 2 Jun 2022 18:00:02 +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 : 4e467261560f087e0c75452646695a4edbb09de7
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 : 1072e4c45dc3e4a9a62b34087414627b307e10f6
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: fix a couple of erroneous examples.
commit : 80cd99c55802d4e4517049dea341ccb356cfa3ba
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Jun 2022 10:39:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Jun 2022 10:39:46 -0400
The example given for anyelement <@ anymultirange didn't return
true as claimed; adjust it so it does.
In passing, change a couple of sample results where the modern
numeric-based logic produces a different number of trailing zeroes
than before.
Erik Rijkers
Discussion: https://postgr.es/m/cc35735d-1ec1-5bb3-9e27-cddbab7afa23@xs4all.nl
M doc/src/sgml/func.sgml
Doc: mention limitation of the number of resultset columns
commit : f2a0060a9bfb7a6f257a536de5ea2d4f7cedff03
author : David Rowley <drowley@postgresql.org>
date : Wed, 1 Jun 2022 12:46:18 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 1 Jun 2022 12:46:18 +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
Recommend scram-sha-256 instead of md5 authentication in docs
commit : a694cf4ca496a7db66a61f6ec2a15a9af6493cef
author : Magnus Hagander <magnus@hagander.net>
date : Tue, 31 May 2022 21:59:47 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Tue, 31 May 2022 21:59:47 +0200
PostgreSQL 14 changed the default to be scram-sha-256, so we should stop
recommending the user to use md5 or even worse password.
Suggested-By: Daniel Westermann
Author: Jonathan S. Katz
Backpatch-through: 14
Discussion: https://postgr.es/m/GV0P278MB0419A8BAC0B0B84AFA5263D9D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM
M doc/src/sgml/runtime.sgml
Revert changes to CONCURRENTLY that "sped up" Xmin advance
commit : 042b584c7f7d6216c54359c0ee0f613ba3b3d9c2
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 31 May 2022 21:24:59 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 31 May 2022 21:24:59 +0200
This reverts commit d9d076222f5b "VACUUM: ignore indexing operations
with CONCURRENTLY".
These changes caused indexes created with the CONCURRENTLY option to
miss heap tuples that were HOT-updated and HOT-pruned during the index
creation. Before these changes, HOT pruning would have been prevented
by the Xmin of the transaction creating the index, but because this
change was precisely to allow the Xmin to move forward ignoring that
backend, now other backends scanning the table can prune them. This is
not a problem for VACUUM (which requires a lock that conflicts with a
CREATE INDEX CONCURRENTLY operation), but HOT-prune can definitely
occur. In other words, Xmin advancement was sped up, but at the cost of
corrupting the resulting index.
Regrettably, this means that the new feature in PG14 that RIC/CIC on
very large tables no longer force VACUUM to retain very old tuples goes
away. We might try to implement it again in a later release, but for
now the risk of indexes missing tuples is too high and there's no easy
fix.
Backpatch to 14, where this change appeared.
Reported-by: Peter Slavov <pet.slavov@gmail.com>
Diagnosys-by: Andrey Borodin <x4mmm@yandex-team.ru>
Diagnosys-by: Michael Paquier <michael@paquier.xyz>
Diagnosys-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/17485-396609c6925b982d%40postgresql.org
M doc/src/sgml/ref/create_index.sgml
M doc/src/sgml/ref/reindex.sgml
M src/backend/storage/ipc/procarray.c
Ensure ParseTzFile() closes the input file after failing.
commit : c47a558528dd79fe76c698cde7e23f38610b05ed
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 : a18b2a3fbcf16998faeb35fc2341708983769841
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 : 0adff38da4bc88bcbcc07641ddc04180fe183188
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 30 May 2022 10:50:32 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 30 May 2022 10:50:32 +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
Fix COPY FROM when database encoding is SQL_ASCII.
commit : f82595ac903e4e4062d909e73693dd809c6845c0
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 29 May 2022 23:53:45 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 29 May 2022 23:53:45 +0300
In the codepath when no encoding conversion is required, the check for
incomplete character at the end of input incorrectly used server
encoding's max character length, instead of the client's. Usually the
server and client encodings are the same when we're not performing
encoding conversion, but SQL_ASCII is an exception.
In the passing, also fix some outdated comments that still talked about
the old COPY protocol. It was removed in v14.
Per bug #17501 from Vitaly Voronov. Backpatch to v14 where this was
introduced.
Discussion: https://www.postgresql.org/message-id/17501-128b1dd039362ae6@postgresql.org
M src/backend/commands/copyfromparse.c
Doc: fix missing/bogus documentation of range_intersect_agg().
commit : 9f2d1946d4b41a27cb5b62da7a5f070acc62cd4e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 29 May 2022 13:25:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 29 May 2022 13:25:21 -0400
The form taking anymultirange had not been documented. This was
fixed in HEAD in b21c4cf95, but that should have been back-patched
to v14 since the function was added there. Do so now.
Also, the form taking anyrange was incorrectly documented as
returning anymultirange, when it returns anyrange.
Remove b21c4cf95 from the v15 release notes, since it no longer
qualifies as new-in-v15.
Noted by Shay Rojansky.
Discussion: https://postgr.es/m/CADT4RqAktzP7t6SFf0Xqm9YhahzvsmxFbzXe-gFOd=+_CHm0JA@mail.gmail.com
M doc/src/sgml/func.sgml
Handle NULL for short descriptions of custom GUC variables
commit : fe441a0319405a52e773e8f3750e925ecc5d86eb
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 28 May 2022 12:12:46 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 28 May 2022 12:12:46 +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 : b4be4a082bde8b4f3caca6fa3127af005720f2d8
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 : a5fc06bf31352fc57cb34ccbf2ca18214118ab9b
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 26 May 2022 12:54:57 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 26 May 2022 12:54:57 -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 : 6f7eec1193f8ddafb6d7ff495d3ce2eb01202a86
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 : 7f798e89367878c0637d6152365b7452b052f3d5
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 21 May 2022 19:05:54 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 21 May 2022 19:05:54 +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 : 58b088a9b3c2ec19998a3822190afdd6af847efe
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
doc: Explain 'invalid' index state for CREATE INDEX CONCURRENTLY
commit : aa783575294f6e3579b9c78a75d54a693f010213
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 20 May 2022 10:05:31 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 20 May 2022 10:05:31 +0200
It wasn't previously mentioned that the index is created as invalid,
which is confusing to new users.
Backpatch to 14 (only because of a conflict in 13).
Author: Laurenz Albe <laurenz.albe@cybertec.at>
Reported-by: Lauren Fliksteen <dancernerd32@gmail.com>
Reviewed-by: Rajakavitha Kodhandapani <krajakavitha@gmail.com>
Discussion: https://postgr.es/m/165290238488.670.7500177735573254738@wrigleys.postgresql.org
M doc/src/sgml/ref/create_index.sgml
Doc: clarify location of libpq's default service file on Windows.
commit : 3a8d83cae35e887be0011fa6139c83423037bc67
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 : 8d9d1286acf9f209243cbcddc53cc4c875a90e20
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
Fix incorrect comments for Memoize struct