Stamp 12.8.
commit : de835071fda945fb5e40340d3ea8dd2ca13e725c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Aug 2021 16:50:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Aug 2021 16:50:41 -0400
M configure
M configure.in
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Last-minute updates for release notes.
commit : c6afcafafe95df08f98eea7ac5d5b3ab30f22db4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Aug 2021 14:41:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Aug 2021 14:41:00 -0400
Security: CVE-2021-3677
M doc/src/sgml/release-12.sgml
Translation updates
commit : 210064bcbe67fce7a12acfd4712ac2804b3c7ddd
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 Aug 2021 12:36:42 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 Aug 2021 12:36:42 +0200
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 23cf9b8788f68be9552d0258c17d1bfc1f3aaa3d
M src/backend/po/de.po
M src/backend/po/fr.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_resetwal/po/de.po
M src/bin/pg_upgrade/po/de.po
M src/bin/psql/po/de.po
M src/bin/psql/po/fr.po
Doc: Fix misleading statement about VACUUM memory limits
commit : 5c7522d111ed13e485f54af5cc247f39a6303e1b
author : David Rowley <drowley@postgresql.org>
date : Mon, 9 Aug 2021 16:48:01 +1200
committer: David Rowley <drowley@postgresql.org>
date : Mon, 9 Aug 2021 16:48:01 +1200
In ec34040af I added a mention that there was no point in setting
maintenance_work_limit to anything higher than 1GB for vacuum, but that
was incorrect as ginInsertCleanup() also looks at what
maintenance_work_mem is set to during VACUUM and that's not limited to
1GB.
Here I attempt to make it more clear that the limitation is only around
the number of dead tuple identifiers that we can collect during VACUUM.
I've also added a note to autovacuum_work_mem to mention this limitation.
I didn't do that in ec34040af as I'd had some wrong-headed ideas about
just limiting the maximum value for that GUC to 1GB.
Author: David Rowley
Discussion: https://postgr.es/m/CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com
Backpatch-through: 9.6, same as ec34040af
M doc/src/sgml/config.sgml
doc: mention pg_upgrade extension script
commit : be500101705c65104af41eaad5e36906b52f44b2
author : Bruce Momjian <bruce@momjian.us>
date : Sun, 8 Aug 2021 21:05:46 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sun, 8 Aug 2021 21:05:46 -0400
Since commit e462856a7a, pg_upgrade automatically creates a script to
update extensions, so mention that instead of ALTER EXTENSION.
Backpatch-through: 9.6
M doc/src/sgml/ref/pgupgrade.sgml
Doc: remove bogus <indexterm> items.
commit : 08ef2ce204573688a3216de39dd7fc2744a563a6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Aug 2021 15:35:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Aug 2021 15:35:30 -0400
Copy-and-pasteo in 665c5855e, evidently. The 9.6 docs toolchain
whined about duplicate index entries, though our modern toolchain
doesn't. In any case, these GUCs surely are not about the
default settings of these values.
M doc/src/sgml/config.sgml
Release notes for 13.4, 12.8, 11.13, 10.18, 9.6.23.
commit : f5b325b967d150d2be579d4541963b2e9c361f59
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Aug 2021 14:35:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Aug 2021 14:35:19 -0400
M doc/src/sgml/release-12.sgml
Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.
commit : 1ff1e4a60646c9732abe16ee5cbb5ffcb30d89a1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Aug 2021 13:29:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Aug 2021 13:29:32 -0400
Rather than trying to pick table aliases that won't conflict with
any possible user-defined matview column name, adjust the queries'
syntax so that the aliases are only used in places where they can't be
mistaken for column names. Mostly this consists of writing "alias.*"
not just "alias", which adds clarity for humans as well as machines.
We do have the issue that "SELECT alias.*" acts differently from
"SELECT alias", but we can use the same hack ruleutils.c uses for
whole-row variables in SELECT lists: write "alias.*::compositetype".
We might as well revert to the original aliases after doing this;
they're a bit easier to read.
Like 75d66d10e, back-patch to all supported branches.
Discussion: https://postgr.es/m/2488325.1628261320@sss.pgh.pa.us
M src/backend/commands/matview.c
M src/test/regress/expected/matview.out
M src/test/regress/sql/matview.sql
Adjust the integer overflow tests in the numeric code.
commit : cc4420f8829ddbc852e8c98781f09401ef26031d
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 6 Aug 2021 21:31:58 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 6 Aug 2021 21:31:58 +0100
Formerly, the numeric code tested whether an integer value of a larger
type would fit in a smaller type by casting it to the smaller type and
then testing if the reverse conversion produced the original value.
That's perfectly fine, except that it caused a test failure on
buildfarm animal castoroides, most likely due to a compiler bug.
Instead, do these tests by comparing against PG_INT16/32_MIN/MAX. That
matches existing code in other places, such as int84(), which is more
widely tested, and so is less likely to go wrong.
While at it, add regression tests covering the numeric-to-int8/4/2
conversions, and adjust the recently added tests to the style of
434ddfb79a (on the v11 branch) to make failures easier to diagnose.
Per buildfarm via Tom Lane, reviewed by Tom Lane.
Discussion: https://postgr.es/m/2394813.1628179479%40sss.pgh.pa.us
M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
Fix wording
commit : 0afe231a0db6442eed6c9d3fe22745405597943a
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Aug 2021 20:55:59 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Aug 2021 20:55:59 +0200
M doc/src/sgml/rules.sgml
M src/backend/utils/adt/rangetypes_selfuncs.c
M src/backend/utils/adt/rangetypes_spgist.c
M src/bin/pg_resetwal/pg_resetwal.c
postgres_fdw: Fix issues with generated columns in foreign tables.
commit : bbc0cd8fa5f158339e07a737550f3322db0fa307
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 5 Aug 2021 20:00:04 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 5 Aug 2021 20:00:04 +0900
postgres_fdw imported generated columns from the remote tables as plain
columns, and caused failures like "ERROR: cannot insert a non-DEFAULT
value into column "foo"" when inserting into the foreign tables, as it
tried to insert values into the generated columns. To fix, we do the
following under the assumption that generated columns in a postgres_fdw
foreign table are defined so that they represent generated columns in
the underlying remote table:
* Send DEFAULT for the generated columns to the foreign server on insert
or update, not generated column values computed on the local server.
* Add to postgresImportForeignSchema() an option "import_generated" to
include column generated expressions in the definitions of foreign
tables imported from a foreign server. The option is true by default.
The assumption seems reasonable, because that would make a query of the
postgres_fdw foreign table return values for the generated columns that
are consistent with the generated expression.
While here, fix another issue in postgresImportForeignSchema(): it tried
to include column generated expressions as column default expressions in
the foreign table definitions when the import_default option was enabled.
Per bug #16631 from Daniel Cherniy. Back-patch to v12 where generated
columns were added.
Discussion: https://postgr.es/m/16631-e929fe9db0ffc7cf%40postgresql.org
M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
M doc/src/sgml/postgres-fdw.sgml
Fix division-by-zero error in to_char() with 'EEEE' format.
commit : 43644bd3b234091c4bfad0bf6d7d88f90c52aaf5
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 5 Aug 2021 09:30:37 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 5 Aug 2021 09:30:37 +0100
This fixes a long-standing bug when using to_char() to format a
numeric value in scientific notation -- if the value's exponent is
less than -NUMERIC_MAX_DISPLAY_SCALE-1 (-1001), it produced a
division-by-zero error.
The reason for this error was that get_str_from_var_sci() divides its
input by 10^exp, which it produced using power_var_int(). However, the
underflow test in power_var_int() causes it to return zero if the
result scale is too small. That's not a problem for power_var_int()'s
only other caller, power_var(), since that limits the rscale to 1000,
but in get_str_from_var_sci() the exponent can be much smaller,
requiring a much larger rscale. Fix by introducing a new function to
compute 10^exp directly, with no rscale limit. This also allows 10^exp
to be computed more efficiently, without any numeric multiplication,
division or rounding.
Discussion: https://postgr.es/m/CAEZATCWhojfH4whaqgUKBe8D5jNHB8ytzemL-PnRx+KCTyMXmg@mail.gmail.com
M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
C comment: correct heading of extension query
commit : 165506217df417c7ca11770599e64d5e93a96fb6
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 12:26:08 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 12:26:08 -0400
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20210803161345.GZ12533@telsasoft.com
Backpatch-through: 9.6
M src/bin/pg_upgrade/version.c
doc: interval spill method for units greater than months
commit : 606d041cb9b6f85140ada1a465c4488c305209cc
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 12:17:58 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 12:17:58 -0400
Units are _truncated_ to months, but only in back branches since the
recent commit.
Reported-by: Bryn Llewellyn
Discussion: https://postgr.es/m/BDAE4B56-3337-45A2-AC8A-30593849D6C0@yugabyte.com
Backpatch-through: 9.6 to 14
M doc/src/sgml/datatype.sgml
pg_upgrade: warn about extensions that need updating
commit : 49e319ceac2e7485859d79e37169009cef10ee88
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:58:15 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:58:15 -0400
Also create a script that can be run to update them.
Reported-by: Dave Cramer
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com
Backpatch-through: 9.6
M src/bin/pg_upgrade/check.c
M src/bin/pg_upgrade/pg_upgrade.h
M src/bin/pg_upgrade/version.c
pg_upgrade: improve docs about extension upgrades
commit : ead4ae00b8c8219498452204a0de6b091ccc1d8a
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:27:32 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:27:32 -0400
The previous wording was unclear about the steps needed to upgrade
extensions, and how to update them after pg_upgrade.
Reported-by: Dave Cramer
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com
Backpatch-through: 9.6
M doc/src/sgml/ref/pgupgrade.sgml
doc: mention inheritance's tableoid can be used in partitioning
commit : 22023dd560c42dead7e77ae220dbee013a037285
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:11:51 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:11:51 -0400
Previously tableoid was not mentioned in the partition doc section. We
only had a link to the "all the normal rules" of inheritance section.
Reported-by: michal.palenik@freemap.sk
Discussion: https://postgr.es/m/162627031219.693.11508199541771263335@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/ddl.sgml
doc: add example of using pg_dump with GNU split and gzip
commit : 2c4fdfef503394034b7e49b88cc747196258c33b
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 10:57:32 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 10:57:32 -0400
This is only possible with GNU split, not other versions like BSD split.
Reported-by: jim@jdoherty.net
Discussion: https://postgr.es/m/162653459215.701.6323855956817776386@wrigleys.postgresql.org
Backpatch-through: 9.6
M doc/src/sgml/backup.sgml
Use elog, not Assert, to report failure to provide an outer snapshot.
commit : f260436459a67e320937d656b2c93604615ed1e5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 31 Jul 2021 11:50:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 31 Jul 2021 11:50:14 -0400
As of commit 84f5c2908, executing SQL commands (via SPI or otherwise)
requires having either an active Portal, or a caller-established
active snapshot. We were simply Assert'ing that that's the case.
But we've now had a couple different reports of people testing
extensions that didn't meet this requirement, and were confused by
the resulting crash. Let's convert the Assert to a test-and-elog,
in hopes of making the issue clearer for extension authors.
Per gripes from Liu Huailing and RekGRpth. Back-patch to v11,
like the prior commit.
Discussion: https://postgr.es/m/OSZPR01MB6215671E3C5956A034A080DFBEEC9@OSZPR01MB6215.jpnprd01.prod.outlook.com
Discussion: https://postgr.es/m/17035-14607d308ac8643c@postgresql.org
M src/backend/tcop/pquery.c
Fix corner-case errors and loss of precision in numeric_power().
commit : 5c62920fa938644935418226872b360f90e74b62
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 31 Jul 2021 11:27:02 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 31 Jul 2021 11:27:02 +0100
This fixes a couple of related problems that arise when raising
numbers to very large powers.
Firstly, when raising a negative number to a very large integer power,
the result should be well-defined, but the previous code would only
cope if the exponent was small enough to go through power_var_int().
Otherwise it would throw an internal error, attempting to take the
logarithm of a negative number. Fix this by adding suitable handling
to the general case in power_var() to cope with negative bases,
checking for integer powers there.
Next, when raising a (positive or negative) number whose absolute
value is slightly less than 1 to a very large power, the result should
approach zero as the power is increased. However, in some cases, for
sufficiently large powers, this would lose all precision and return 1
instead of 0. This was due to the way that the local_rscale was being
calculated for the final full-precision calculation:
local_rscale = rscale + (int) val - ln_dweight + 8
The first two terms on the right hand side are meant to give the
number of significant digits required in the result ("val" being the
estimated result weight). However, this failed to account for the fact
that rscale is clipped to a maximum of NUMERIC_MAX_DISPLAY_SCALE
(1000), and the result weight might be less then -1000, causing their
sum to be negative, leading to a loss of precision. Fix this by
forcing the number of significant digits calculated to be nonnegative.
It's OK for it to be zero (when the result weight is less than -1000),
since the local_rscale value then includes a few extra digits to
ensure an accurate result.
Finally, add additional underflow checks to exp_var() and power_var(),
so that they consistently return zero for cases like this where the
result is indistinguishable from zero. Some paths through this code
already returned zero in such cases, but others were throwing overflow
errors.
Dean Rasheed, reviewed by Yugo Nagata.
Discussion: http://postgr.es/m/CAEZATCW6Dvq7+3wN3tt5jLj-FyOcUgT5xNoOqce5=6Su0bCR0w@mail.gmail.com
M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
Fix range check in ECPG numeric to int conversion
commit : d9589eb62a2b4bb43a7893b0bb1acd6eb1bdfe9b
author : John Naylor <john.naylor@postgresql.org>
date : Fri, 30 Jul 2021 13:50:23 -0400
committer: John Naylor <john.naylor@postgresql.org>
date : Fri, 30 Jul 2021 13:50:23 -0400
The previous coding guarded against -INT_MAX instead of INT_MIN,
leading to -2147483648 being rejected as out of range.
Per bug #17128 from Kevin Sweet
Discussion: https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.org
Reviewed-by: Tom Lane
Backpatch to all supported branches
M doc/src/sgml/ecpg.sgml
M src/interfaces/ecpg/pgtypeslib/numeric.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test.stderr
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test.stdout
M src/interfaces/ecpg/test/pgtypeslib/num_test.pgc
Update minimum recovery point on truncation during WAL replay of abort record.
commit : d7ded08e6e0e565adf6fea7c55bfcf2845e5f8cc
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 29 Jul 2021 01:34:13 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 29 Jul 2021 01:34:13 +0900
If a file is truncated, we must update minRecoveryPoint. Once a file is
truncated, there's no going back; it would not be safe to stop recovery
at a point earlier than that anymore.
Commit 7bffc9b7bf changed xact_redo_commit() so that it updates
minRecoveryPoint on truncation, but forgot to change xact_redo_abort().
Back-patch to all supported versions.
Reported-by: mengjuan.cmj@alibaba-inc.com
Author: Fujii Masao
Reviewed-by: Heikki Linnakangas
Discussion: https://postgr.es/m/b029fce3-4fac-4265-968e-16f36ff4d075.mengjuan.cmj@alibaba-inc.com
M src/backend/access/transam/xact.c
Doc: Clarify lock levels taken during ATTACH PARTITION
commit : c590904d50cc93b12fc895041c34e1ea821e768c
author : David Rowley <drowley@postgresql.org>
date : Wed, 28 Jul 2021 15:01:10 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 28 Jul 2021 15:01:10 +1200
It wasn't all that clear which lock levels, if any, would be held on the
DEFAULT partition during an ATTACH PARTITION operation.
Also, clarify which locks will be taken if the DEFAULT partition or the
table being attached are themselves partitioned tables.
Here I'm only backpatching to v12 as before then we obtained an ACCESS
EXCLUSIVE lock on the partitioned table. It seems much less relevant to
mention which locks are taken on other tables when the partitioned table
itself is locked with an ACCESS EXCLUSIVE lock.
Author: Matthias van de Meent, David Rowley
Discussion: https://postgr.es/m/CAEze2WiTB6iwrV8W_J=fnrnZ7fowW3qu-8iQ8zCHP3FiQ6+o-A@mail.gmail.com
Backpatch-through: 12
M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/alter_table.sgml
Set pg_setting.pending_restart when pertinent config lines are removed
commit : 6feb229f53f8de704ee2ff709d2c44e1c4d6be92
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Jul 2021 15:44:12 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Jul 2021 15:44:12 -0400
This changes the behavior of examining the pg_file_settings view after
changing a config option that requires restart. The user needs to know
that any change of such options does not take effect until a restart,
and this worked correctly if the line is edited without removing it.
However, for the case where the line is removed altogether, the flag
doesn't get set, because a flag was only set in set_config_option, but
that's not called for lines removed. Repair.
(Ref.: commits 62d16c7fc561 and a486e35706ea)
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/202107262302.xsfdfc5sb7sh@alvherre.pgsql
M src/backend/utils/misc/guc-file.l
Avoid using ambiguous word "non-negative" in error messages.
commit : de87c481f635953e84e7d3b404e15700301bcdac
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 28 Jul 2021 01:21:52 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 28 Jul 2021 01:21:52 +0900
The error messages using the word "non-negative" are confusing
because it's ambiguous about whether it accepts zero or not.
This commit improves those error messages by replacing it with
less ambiguous word like "greater than zero" or
"greater than or equal to zero".
Also this commit added the note about the word "non-negative" to
the error message style guide, to help writing the new error messages.
When postgres_fdw option fetch_size was set to zero, previously
the error message "fetch_size requires a non-negative integer value"
was reported. This error message was outright buggy. Therefore
back-patch to all supported versions where such buggy error message
could be thrown.
Reported-by: Hou Zhijie
Author: Bharath Rupireddy
Reviewed-by: Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/OS0PR01MB5716415335A06B489F1B3A8194569@OS0PR01MB5716.jpnprd01.prod.outlook.com
M contrib/postgres_fdw/option.c
M doc/src/sgml/sources.sgml
M src/backend/partitioning/partbounds.c
M src/backend/utils/adt/tsquery_op.c
M src/test/modules/test_shm_mq/test.c
M src/test/regress/expected/hash_part.out
pg_resetxlog: add option to set oldest xid & use by pg_upgrade
commit : 7626e9f2be7d0fc9b20936910831b900b555728b
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 26 Jul 2021 22:38:14 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 26 Jul 2021 22:38:14 -0400
Add pg_resetxlog -u option to set the oldest xid in pg_control.
Previously -x set this value be -2 billion less than the -x value.
However, this causes the server to immediately scan all relation's
relfrozenxid so it can advance pg_control's oldest xid to be inside the
autovacuum_freeze_max_age range, which is inefficient and might disrupt
diagnostic recovery. pg_upgrade will use this option to better create
the new cluster to match the old cluster.
Reported-by: Jason Harvey, Floris Van Nee
Discussion: https://postgr.es/m/20190615183759.GB239428@rfd.leadboat.com, 87da83168c644fd9aae38f546cc70295@opammb0562.comp.optiver.com
Author: Bertrand Drouvot
Backpatch-through: 9.6
M doc/src/sgml/ref/pg_resetwal.sgml
M src/bin/pg_resetwal/pg_resetwal.c
M src/bin/pg_upgrade/controldata.c
M src/bin/pg_upgrade/pg_upgrade.c
M src/bin/pg_upgrade/pg_upgrade.h
Fix a couple of memory leaks in src/bin/pg_basebackup/
commit : c4ef3b81b85434b3d2eac8d0cca3a0078898266a
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 26 Jul 2021 11:14:14 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 26 Jul 2021 11:14:14 +0900
These have been introduced by 7fbe0c8, and could happen for
pg_basebackup and pg_receivewal.
Per report from Coverity for the ones in walmethods.c, I have spotted
the ones in receivelog.c after more review.
Backpatch-through: 10
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_basebackup/walmethods.c
M src/bin/pg_basebackup/walmethods.h
Make the standby server promptly handle interrupt signals.
commit : 1bcfda30fb64eb9ed423e0652e02ce04e2dcaad0
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 16 Nov 2020 18:27:51 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 16 Nov 2020 18:27:51 +0900
This commit changes the startup process in the standby server so that
it handles the interrupt signals after waiting for wal_retrieve_retry_interval
on the latch and resetting it, before entering another wait on the latch.
This change causes the standby server to promptly handle interrupt signals.
Otherwise, previously, there was the case where the standby needs to
wait extra five seconds to shutdown when the shutdown request arrived
while the startup process was waiting for wal_retrieve_retry_interval
on the latch.
Author: Fujii Masao, but implementation idea is from Soumyadeep Chakraborty
Reviewed-by: Soumyadeep Chakraborty
Discussion: https://postgr.es/m/9d7e6ab0-8a53-ddb9-63cd-289bcb25fe0e@oss.nttdata.com
Per discussion of BUG #17073, back-patch to all supported versions.
Discussion: https://postgr.es/m/17073-1a5fdaed0fa5d4d0@postgresql.org
M src/backend/access/transam/xlog.c
Fix check for conflicting session- vs transaction-level locks.
commit : 899785b4f6c8c732c233e23c31a93405cff5ec34
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jul 2021 18:35:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jul 2021 18:35:52 -0400
We have an implementation restriction that PREPARE TRANSACTION can't
handle cases where both session-lifespan and transaction-lifespan locks
are held on the same lockable object. (That's because we'd otherwise
need to acquire a new PROCLOCK entry during post-prepare cleanup, which
is an operation that might fail. The situation can only arise with odd
usages of advisory locks, so removing the restriction is probably not
worth the amount of effort it would take.) AtPrepare_Locks attempted
to enforce this, but its logic was many bricks shy of a load, because
it only detected cases where the session and transaction locks had the
same lockmode. Locks of different modes on the same object would lead
to the rather unhelpful message "PANIC: we seem to have dropped a bit
somewhere".
To fix, build a transient hashtable with one entry per locktag,
not one per locktag + mode, and use that to detect conflicts.
Per bug #17122 from Alexander Pyhalov. This bug is ancient,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/17122-04f3c32098a62233@postgresql.org
M src/backend/storage/lmgr/lock.c
M src/test/regress/expected/prepared_xacts.out
M src/test/regress/expected/prepared_xacts_1.out
M src/test/regress/sql/prepared_xacts.sql
Make printf("%s", NULL) print "(null)" instead of crashing.
commit : 4c8a14e8d993e10b9851eb6be225b151bc4e233b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jul 2021 13:41:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jul 2021 13:41:17 -0400
We previously took a hard-line attitude that callers should never print
a null string pointer, and doing so is worthy of an assertion failure
or crash. However, we've long since flushed out any easy-to-find bugs
of that nature. What remains is a lot of code that perhaps could fail
that way in hard-to-reach corner cases. For example, in something as
simple as
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("constraint \"%s\" for table \"%s\" does not exist",
conname, get_rel_name(relid))));
one must wonder whether it's completely guaranteed that get_rel_name
cannot return NULL in this context. If such a situation did occur,
the existing policy converts what might be a pretty minor bug into
a server crash condition. This is not good for robustness.
Hence, let's follow the lead of glibc and print "(null)" instead
of failing. We should, of course, still consider it a bug if that
behavior is reachable in ordinary use; but crashing seems less
desirable than not crashing.
This fix works across-the-board in v12 and up, where we always use
src/port/snprintf.c. Before that, on most platforms we're at the mercy
of the local libc, but it appears that Solaris 10 is the only supported
platform where we'd still get a crash. Most other platforms such as
*BSD, macOS, and Solaris 11 have adopted glibc's behavior at some
point. (AIX and HPUX just print "" not "(null)", but that's close
enough.) I've not checked what Windows' native printf would do, but
it doesn't matter because we've long used snprintf.c on that platform.
In v12 and up, also const-ify related code so that we're not casting
away const on the constant string. This is just neatnik-ism, since
next to no compilers will warn about that.
Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org
M src/port/snprintf.c
jit: Don't inline functions that access thread-locals.
commit : b2f759e35f7598ee36d68283a9fd8e9219e11441
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 22 Jul 2021 14:11:17 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 22 Jul 2021 14:11:17 +1200
Code inlined by LLVM can crash or fail with "Relocation type not
implemented yet!" if it tries to access thread local variables. Don't
inline such code.
Back-patch to 11, where LLVM arrived. Bug #16696.
Author: Dmitry Marakasov <amdmi3@amdmi3.ru>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/16696-29d944a33801fbfe@postgresql.org
M src/backend/jit/llvm/llvmjit_inline.cpp
Document "B" and "us" as accepted units in postgres.conf.sample
commit : 4b39d5c69a67caebe648ce4c32083f162bd239e1
author : John Naylor <john.naylor@postgresql.org>
date : Wed, 21 Jul 2021 10:17:07 -0400
committer: John Naylor <john.naylor@postgresql.org>
date : Wed, 21 Jul 2021 10:17:07 -0400
In postgresql.conf, memory and file size GUCs can be specified with "B"
(bytes) as of b06d8e58b. Likewise, time GUCs can be specified with "us"
(microseconds) as of caf626b2c. Update postgres.conf.sample to reflect
that fact.
Pavel Luzanov
Backpatch to v12, which is the earliest version that allows both of
these units. A separate commit will document the "B" case for v11.
Discussion: https://www.postgresql.org/message-id/flat/f10d16fc-8fa0-1b3c-7371-cb3a35a13b7a%40postgrespro.ru
M src/backend/utils/misc/postgresql.conf.sample
doc: Document that only superusers can use pg_import_system_collations().
commit : fe4941fdfc21cf541be779ebc0b3fee3bd2a02fb
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 21 Jul 2021 13:52:37 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 21 Jul 2021 13:52:37 +0900
Back-patch to v10 where pg_import_system_collations() was added.
Author: Atsushi Torikoshi
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/b7f484692a3e283710032e68b7f40617@oss.nttdata.com
M doc/src/sgml/func.sgml
Fix corner-case uninitialized-variable issues in plpgsql.
commit : 85189f54a15ae7d06523ab0bdf1959ff36fdc776
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 Jul 2021 13:01:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 Jul 2021 13:01:48 -0400
If an error was raised during our initial attempt to check whether
a successfully-compiled expression is "simple", subsequent calls of
exec_stmt_execsql would suppose that stmt->mod_stmt was already computed
when it had not been. This could lead to assertion failures in debug
builds; in production builds the effect would typically be to act as
if INTO STRICT had been specified even when it had not been. Of course
that only matters if the subsequent attempt to execute the expression
succeeds, so that the problem can only be reached by fixing a failure
in some referenced, inline-able SQL function and then retrying the
calling plpgsql function in the same session.
(There might be even-more-obscure ways to change the expression's
behavior without changing the plpgsql function, but that one seems
like the only one people would be likely to hit in practice.)
The most foolproof way to fix this would be to arrange for
exec_prepare_plan to not set expr->plan until we've finished the
subsidiary simple-expression check. But it seems hard to do that
without creating reference-count leak issues. So settle for documenting
the hazard in a comment and fixing exec_stmt_execsql to test separately
for whether it's computed stmt->mod_stmt. (That adds a test-and-branch
per execution, but hopefully that's negligible in context.) In v11 and
up, also fix exec_stmt_call which had a variant of the same issue.
Per bug #17113 from Alexander Lakhin. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/17113-077605ce00e0e7ec@postgresql.org
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/pl_gram.y
M src/pl/plpgsql/src/plpgsql.h
Fix some issues with WAL segment opening for pg_receivewal --compress
commit : b9a0de15eb2920956af64189cb87ecd7869bf60f
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Jul 2021 12:12:54 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Jul 2021 12:12:54 +0900
The logic handling the opening of new WAL segments was fuzzy when using
--compress if a partial, non-compressed, segment with the same base name
existed in the repository storing those files. In this case, using
--compress would cause the code to first check for the existence and the
size of a non-compressed segment, followed by the opening of a new
compressed, partial, segment. The code was accidentally working
correctly on most platforms as the buildfarm has proved, except
bowerbird where gzflush() could fail in this code path. It is wrong
anyway to take the code path used pre-padding when creating a new
partial, non-compressed, segment, so let's fix it.
Note that this issue exists when users mix successive runs of
pg_receivewal with or without compression, as discovered with the tests
introduced by ffc9dda.
While on it, this refactors the code so as code paths that need to know
about the ".gz" suffix are down from four to one in walmethods.c, easing
a bit the introduction of new compression methods. This addresses a
second issue where log messages generated for an unexpected failure
would not show the compressed segment name involved, which was
confusing, printing instead the name of the non-compressed equivalent.
Reported-by: Georgios Kokolatos
Discussion: https://postgr.es/m/YPDLz2x3o1aX2wRh@paquier.xyz
Backpatch-through: 10
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_basebackup/walmethods.c
M src/bin/pg_basebackup/walmethods.h
Don't allow to set replication slot_name as ''.
commit : f2f459f182fc8b1af44e422e2324b7acd5ee2408
author : Amit Kapila <akapila@postgresql.org>
date : Mon, 19 Jul 2021 11:15:03 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Mon, 19 Jul 2021 11:15:03 +0530
We don't allow to create replication slot_name as an empty string ('') via
SQL API pg_create_logical_replication_slot() but it is allowed to be set
via Alter Subscription command. This will lead to apply worker repeatedly
keep trying to stream data via slot_name '' and the user is not allowed to
create the slot with that name.
Author: Japin Li
Reviewed-By: Ranier Vilela, Amit Kapila
Backpatch-through: 10, where it was introduced
Discussion: https://postgr.es/m/MEYP282MB1669CBD98E721C77CA696499B61A9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
M src/backend/commands/subscriptioncmds.c
M src/test/regress/expected/subscription.out
M src/test/regress/sql/subscription.sql
doc: Mention CASCADE/RESTRICT for DROP STATISTICS
commit : df12b625a6885cd200e580ebcc605209a16e17ad
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 19 Jul 2021 12:39:57 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 19 Jul 2021 12:39:57 +0900
This grammar has no effect as there are no dependencies on statistics,
but it is supported by the parser. This is more consistent with the
other DROP commands.
Author: Vignesh C
Discussion: https://postgr.es/m/CALDaNm1LA=yNmzcSfy+0oe6CEAgsxXRf_-UutE3ZncFi8QkFNQ@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/ref/drop_statistics.sgml
Doc: document the current-transaction-modes GUCs.
commit : bb9beade258108071078ae9233084b8a4bb4581e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 Jul 2021 11:52:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 Jul 2021 11:52:54 -0400
We had documentation of default_transaction_isolation et al,
but for some reason not of transaction_isolation et al.
AFAICS this is just an ancient oversight, so repair.
Per bug #17077 from Yanliang Lei.
Discussion: https://postgr.es/m/17077-ade8e166a01e1374@postgresql.org
M doc/src/sgml/config.sgml
M doc/src/sgml/ref/set_transaction.sgml
Fix pg_dump for disabled triggers on partitioned tables
commit : 5992c94dc7e4782760094a13be632a39ba4beffd
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 16 Jul 2021 17:29:22 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 16 Jul 2021 17:29:22 -0400
pg_dump failed to preserve the 'enabled' flag (which can be not only
disabled, but also REPLICA or ALWAYS) for partitions which had it
changed from their respective parents. Attempt to handle that by
including a definition for such triggers in the dump, but replace the
standard CREATE TRIGGER line with an ALTER TRIGGER line.
Backpatch to 11, where these triggers can exist. In branches 11 and 12,
pick up a few test lines from commit b9b408c48724 to verify that
pg_upgrade is okay with these arrangements.
Co-authored-by: Justin Pryzby <pryzby@telsasoft.com>
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/20200930223450.GA14848@telsasoft.com
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/pg_dump/t/002_pg_dump.pl
M src/test/regress/expected/sanity_check.out
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Preserve firing-on state when cloning row triggers to partitions
commit : 7584ec1f60980ee855aa34d8159f7f9cddc289af
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 16 Jul 2021 13:01:43 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 16 Jul 2021 13:01:43 -0400
When triggers are cloned from partitioned tables to their partitions,
the 'tgenabled' flag (origin/replica/always/disable) was not propagated.
Make it so that the flag on the trigger on partition is initially set to
the same value as on the partitioned table.
Add a test case to verify the behavior.
Backpatch to 11, where this appeared in commit 86f575948c77.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reported-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20200930223450.GA14848@telsasoft.com
M src/backend/commands/tablecmds.c
M src/backend/commands/trigger.c
M src/include/commands/trigger.h
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Fix unexpected error messages for various flavors of ALTER TABLE
commit : b242e1d239df238d612ad7037a1218cc47c641a4
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 14 Jul 2021 17:15:26 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 14 Jul 2021 17:15:26 +0900
Some commands of ALTER TABLE could fail with the following error:
ERROR: "tab" is of the wrong type
This error is unexpected, as all the code paths leading to
ATWrongRelkindError() should use a supported set of relkinds to generate
correct error messages. This commit closes the gap with such mistakes,
by adding all the missing relkind combinations. Tests are added to
check all the problems found. Note that some combinations are not used,
but these are left around as it could have an impact on applications
relying on this code.
2ed532e has done a much larger refactoring on HEAD to make such error
messages easier to manage in the long-term, so nothing is needed there.
Author: Kyotaro Horiguchi
Reviewed-by: Peter Eisentraut, Ahsan Hadi, Michael Paquier
Discussion: https://postgr.es/m/20210216.181415.368926598204753659.horikyota.ntt@gmail.com
Backpatch-through: 11
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/foreign_data.out
M src/test/regress/sql/alter_table.sql
M src/test/regress/sql/foreign_data.sql
Robustify tuplesort's free_sort_tuple function
commit : 645c5d11939641ce4ad14f7e547e9c5ec2b98f71
author : David Rowley <drowley@postgresql.org>
date : Tue, 13 Jul 2021 13:30:26 +1200
committer: David Rowley <drowley@postgresql.org>
date : Tue, 13 Jul 2021 13:30:26 +1200
41469253e went to the trouble of removing a theoretical bug from
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's
make this a little more robust by also setting the tuple to NULL so that
should we be called again we won't end up doing a pfree on the already
pfree'd tuple. Per advice from Tom Lane.
Discussion: https://postgr.es/m/3188192.1626136953@sss.pgh.pa.us
Backpatch-through: 9.6, same as 41469253e
M src/backend/utils/sort/tuplesort.c
Fix theoretical bug in tuplesort
commit : 6f1c7a2d0fe0a3cf4a46053f50d0931248ba6e73
author : David Rowley <drowley@postgresql.org>
date : Tue, 13 Jul 2021 12:44:36 +1200
committer: David Rowley <drowley@postgresql.org>
date : Tue, 13 Jul 2021 12:44:36 +1200
This fixes a theoretical bug in tuplesort.c which, if a bounded sort was
used in combination with a byval Datum sort (tuplesort_begin_datum), when
switching the sort to a bounded heap in make_bounded_heap(), we'd call
free_sort_tuple(). The problem was that when sorting Datums of a byval
type, the tuple is NULL and free_sort_tuple() would free the memory for it
regardless of that. This would result in a crash.
Here we fix that simply by adding a check to see if the tuple is NULL
before trying to disassociate and free any memory belonging to it.
The reason this bug is only theoretical is that nowhere in the current
code base do we do tuplesort_set_bound() when performing a Datum sort.
However, let's backpatch a fix for this as if any extension uses the code
in this way then it's likely to cause problems.
Author: Ronan Dunklau
Discussion: https://postgr.es/m/CAApHDvpdoqNC5FjDb3KUTSMs5dg6f+XxH4Bg_dVcLi8UYAG3EQ@mail.gmail.com
Backpatch-through: 9.6, oldest supported version
M src/backend/utils/sort/tuplesort.c
doc: Fix typo in function prototype
commit : 9c3113e5737ec75ee65d48527845148826efc3ef
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 12 Jul 2021 22:07:35 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 12 Jul 2021 22:07:35 +0200
M doc/src/sgml/indexam.sgml
Remove dead assignment to local variable.
commit : 4df5f6c26b2d5c89f1bc71eaee34e354974e8b97
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 12 Jul 2021 11:13:33 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 12 Jul 2021 11:13:33 +0300
This should have been removed in commit 7e30c186da, which split the loop
into two. Only the first loop uses the 'from' variable; updating it in
the second loop is bogus. It was never read after the first loop, so this
was harmless and surely optimized away by the compiler, but let's be tidy.
Backpatch to all supported versions.
Author: Ranier Vilela
Discussion: https://www.postgresql.org/message-id/CAEudQAoWq%2BAL3BnELHu7gms2GN07k-np6yLbukGaxJ1vY-zeiQ%40mail.gmail.com
M src/backend/access/nbtree/nbtxlog.c
Lock the extension during ALTER EXTENSION ADD/DROP.
commit : 92340ba5a795ad250fb797168e08ac8ed7838613
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 Jul 2021 12:54:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 Jul 2021 12:54:24 -0400
Although we were careful to lock the object being added or dropped,
we failed to get any sort of lock on the extension itself. This
allowed the ALTER to proceed in parallel with a DROP EXTENSION,
which is problematic for a couple of reasons. If both commands
succeeded we'd be left with a dangling link in pg_depend, which
would cause problems later. Also, if the ALTER failed for some
reason, it might try to print the extension's name, and that could
result in a crash or (in older branches) a silly error message
complaining about extension "(null)".
Per bug #17098 from Alexander Lakhin. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org
M src/backend/commands/extension.c
Fix assign_record_type_typmod().
commit : 5b1621d2fb736bcec58114faf035e6ad9bd64a1d
author : Jeff Davis <jdavis@postgresql.org>
date : Fri, 9 Jul 2021 14:15:48 -0700
committer: Jeff Davis <jdavis@postgresql.org>
date : Fri, 9 Jul 2021 14:15:48 -0700
If an error occurred in the wrong place, it was possible to leave an
unintialized entry in the hash table, leading to a crash. Fixed.
Also, be more careful about the order of operations so that an
allocation error doesn't leak memory in CacheMemoryContext or
unnecessarily advance NextRecordTypmod.
Backpatch through version 11. Earlier versions (prior to 35ea75632a5)
do not exhibit the problem, because an uninitialized hash entry
contains a valid empty list.
Author: Sait Talha Nisanci <Sait.Nisanci@microsoft.com>
Reviewed-by: Andres Freund
Discussion: https://postgr.es/m/HE1PR8303MB009069D476225B9A9E194B8891779@HE1PR8303MB0090.EURPRD83.prod.outlook.com
Backpatch-through: 11
M src/backend/utils/cache/typcache.c
Fix busted test for ldap_initialize.
commit : 03fc042eb628759d1009c28e81aae776ed9358a2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 Jul 2021 13:19:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 Jul 2021 13:19:31 -0400
Sigh ... I was expecting AC_CHECK_LIB to do something it didn't,
namely update LIBS. This led to not finding ldap_initialize.
Fix by moving the probe for ldap_initialize. In some sense this
is more correct anyway, since (at least for now) we care about
whether ldap_initialize exists in libldap not libldap_r.
Per buildfarm member elver and local testing.
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org
M configure
M configure.in
Fix numeric_mul() overflow due to too many digits after decimal point.
commit : 357b66ef9470bee657198b4bdb26c98c89e56459
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 10 Jul 2021 12:47:45 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 10 Jul 2021 12:47:45 +0100
This fixes an overflow error when using the numeric * operator if the
result has more than 16383 digits after the decimal point by rounding
the result. Overflow errors should only occur if the result has too
many digits *before* the decimal point.
Discussion: https://postgr.es/m/CAEZATCUmeFWCrq2dNzZpRj5+6LfN85jYiDoqm+ucSXhb9U2TbA@mail.gmail.com
M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
Un-break AIX build, take 2.
commit : e82cde74d8f9669bb0dd48b3cc9f70e91ef26e9f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Jul 2021 16:59:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Jul 2021 16:59:08 -0400
I incorrectly diagnosed the reason why hoverfly is unhappy.
Looking closer, it appears that it fails to link libldap
unless libssl is also present; so the problem was my
idea of clearing LIBS before making the check. Revert
to essentially the original coding, except that instead
of failing when libldap_r isn't there, use libldap.
Per buildfarm member hoverfly.
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org
M configure
M configure.in
Un-break AIX build.
commit : 83a8bf24ea9a4bef21f5c52e52ceb5ba1edd85d3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Jul 2021 14:15:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Jul 2021 14:15:41 -0400
In commit d0a02bdb8, I'd supposed that uniformly probing for
ldap_bind would make the intent clearer. However, that seems
not to work on AIX, for obscure reasons (maybe it's a macro
there?). Revert to the former behavior of probing
ldap_simple_bind for thread-safe cases and ldap_bind otherwise.
Per buildfarm member hoverfly.
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org
M configure
M configure.in
Update configure's probe for libldap to work with OpenLDAP 2.5.
commit : a5377e7f7557439fbe17a3f90596bb07de30c06d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Jul 2021 12:38:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Jul 2021 12:38:55 -0400
The separate libldap_r is gone and libldap itself is now always
thread-safe. Unfortunately there seems no easy way to tell by
inspection whether libldap is thread-safe, so we have to take
it on faith that libldap is thread-safe if there's no libldap_r.
That should be okay, as it appears that libldap_r was a standard
part of the installation going back at least 20 years.
Report and patch by Adrian Ho. Back-patch to all supported
branches, since people might try to build any of them with
a newer OpenLDAP.
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org
M configure
M configure.in
M src/include/pg_config.h.in
Reject cases where a query in WITH rewrites to just NOTIFY.
commit : 9c729bd3084917f31113a434567504f2f9e266d1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Jul 2021 11:02:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Jul 2021 11:02:26 -0400
Since the executor can't cope with a utility statement appearing
as a node of a plan tree, we can't support cases where a rewrite
rule inserts a NOTIFY into an INSERT/UPDATE/DELETE command appearing
in a WITH clause of a larger query. (One can imagine ways around
that, but it'd be a new feature not a bug fix, and so far there's
been no demand for it.) RewriteQuery checked for this, but it
missed the case where the DML command rewrites to *only* a NOTIFY.
That'd lead to crashes later on in planning. Add the missed check,
and improve the level of testing of this area.
Per bug #17094 from Yaoguang Chen. It's been busted since WITH
was introduced, so back-patch to all supported branches.
Discussion: https://postgr.es/m/17094-bf15dff55eaf2e28@postgresql.org
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql
Remove more obsolete comments about semaphores.
commit : c0385c6a7e13bee763855a9bceedc71602ab1572
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 9 Jul 2021 17:51:48 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 9 Jul 2021 17:51:48 +1200
Commit 6753333f stopped using semaphores as the sleep/wake mechanism for
heavyweight locks, but some obsolete references to that scheme remained
in comments. As with similar commit 25b93a29, back-patch all the way.
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/CA%2BhUKGLafjB1uzXcy%3D%3D2L3cy7rjHkqOVn7qRYGBjk%3D%3DtMJE7Yg%40mail.gmail.com
M src/backend/storage/lmgr/lwlock.c
Add missing Int64GetDatum macro in dbsize.c
commit : b1862113931022e6766a4e8ba9036f3d6241677c
author : David Rowley <drowley@postgresql.org>
date : Fri, 9 Jul 2021 15:13:01 +1200
committer: David Rowley <drowley@postgresql.org>
date : Fri, 9 Jul 2021 15:13:01 +1200
I accidentally missed adding this when adjusting 55fe60938 for back
patching. This adjustment was made for 9.6 to 13. 14 and master are not
affected.
Discussion: https://postgr.es/m/CAApHDvp=twCsGAGQG=A=cqOaj4mpknPBW-EZB-sd+5ZS5gCTtA@mail.gmail.com
M src/backend/utils/adt/dbsize.c
Fix incorrect return value in pg_size_pretty(bigint)
commit : efc42a1e18b53e376955ee2c12d89982e80b0830
author : David Rowley <drowley@postgresql.org>
date : Fri, 9 Jul 2021 14:04:56 +1200
committer: David Rowley <drowley@postgresql.org>
date : Fri, 9 Jul 2021 14:04:56 +1200
Due to how pg_size_pretty(bigint) was implemented, it's possible that when
given a negative number of bytes that the returning value would not match
the equivalent positive return value when given the equivalent positive
number of bytes. This was due to two separate issues.
1. The function used bit shifting to convert the number of bytes into
larger units. The rounding performed by bit shifting is not the same as
dividing. For example -3 >> 1 = -2, but -3 / 2 = -1. These two
operations are only equivalent with positive numbers.
2. The half_rounded() macro rounded towards positive infinity. This meant
that negative numbers rounded towards zero and positive numbers rounded
away from zero.
Here we fix #1 by dividing the values instead of bit shifting. We fix #2
by adjusting the half_rounded macro always to round away from zero.
Additionally, adjust the pg_size_pretty(numeric) function to be more
explicit that it's using division rather than bit shifting. A casual
observer might have believed bit shifting was used due to a static
function being named numeric_shift_right. However, that function was
calculating the divisor from the number of bits and performed division.
Here we make that more clear. This change is just cosmetic and does not
affect the return value of the numeric version of the function.
Here we also add a set of regression tests both versions of
pg_size_pretty() which test the values directly before and after the
function switches to the next unit.
This bug was introduced in 8a1fab36a. Prior to that negative values were
always displayed in bytes.
Author: Dean Rasheed, David Rowley
Discussion: https://postgr.es/m/CAEZATCXnNW4HsmZnxhfezR5FuiGgp+mkY4AzcL5eRGO4fuadWg@mail.gmail.com
Backpatch-through: 9.6, where the bug was introduced.
M src/backend/utils/adt/dbsize.c
M src/test/regress/expected/dbsize.out
M src/test/regress/sql/dbsize.sql
Avoid doing catalog lookups in postgres_fdw's conversion_error_callback.
commit : bd2e68d0bf948dc17299624d1db63e18734fb829
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Jul 2021 12:36:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Jul 2021 12:36:13 -0400
As in 50371df26, this is a bad idea since the callback can't really
know what error is being thrown and thus whether or not it is safe
to attempt catalog accesses. Rather than pushing said accesses into
the mainline code where they'd usually be a waste of cycles, we can
look at the query's rangetable instead.
This change does mean that we'll be printing query aliases (if any
were used) rather than the table or column's true name. But that
doesn't seem like a bad thing: it's certainly a more useful definition
in self-join cases, for instance. In any case, it seems unlikely that
any applications would be depending on this detail, so it seems safe
to change.
Patch by me. Original complaint by Andres Freund; Bharath Rupireddy
noted the connection to conversion_error_callback.
Discussion: https://postgr.es/m/20210106020229.ne5xnuu6wlondjpe@alap3.anarazel.de
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
Doc: add info about timestamps with fractional-minute UTC offsets.
commit : eda3b454a891bedd79a59684730efc42fa9e46a3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Jul 2021 10:34:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Jul 2021 10:34:51 -0400
Our code has supported fractional-minute UTC offsets for ages, but
there was no mention of the possibility in the main docs, and only
a very indirect reference in Appendix B. Improve that.
Discussion: https://postgr.es/m/162543102827.697.5755498651217979813@wrigleys.postgresql.org
M doc/src/sgml/datatype.sgml
Reduce overhead of cache-clobber testing in LookupOpclassInfo().
commit : 3edc2dbc00a47ce88acf79d1b7097842cddbd061
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Jul 2021 16:51:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Jul 2021 16:51:57 -0400
Commit 03ffc4d6d added logic to bypass all caching behavior in
LookupOpclassInfo when CLOBBER_CACHE_ALWAYS is enabled. It doesn't
look like I stopped to think much about what that would cost, but
recent investigation shows that the cost is enormous: it roughly
doubles the time needed for cache-clobber test runs.
There does seem to be value in this behavior when trying to test
the opclass-cache loading logic itself, but for other purposes the
cost is excessive. Hence, let's back off to doing this only when
debug_invalidate_system_caches_always is at least 3; or in older
branches, when CLOBBER_CACHE_RECURSIVELY is defined.
While here, clean up some other minor issues in LookupOpclassInfo.
Re-order the code so we aren't left with broken cache entries (leading
to later core dumps) in the unlikely case that we suffer OOM while
trying to allocate space for a new entry. (That seems to be my
oversight in 03ffc4d6d.) Also, in >= v13, stop allocating one array
entry too many. That's evidently left over from sloppy reversion in
851b14b0c.
Back-patch to all supported branches, mainly to reduce the runtime
of cache-clobbering buildfarm animals.
Discussion: https://postgr.es/m/1370856.1625428625@sss.pgh.pa.us
M src/backend/utils/cache/relcache.c
Doc: Hash Indexes.
commit : 73ede4da6b9b7c0d50b04a8e8c15f20b59a33b1c
author : Amit Kapila <akapila@postgresql.org>
date : Mon, 5 Jul 2021 10:01:28 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Mon, 5 Jul 2021 10:01:28 +0530
A new chapter for Hash Indexes, designed to help users understand how
they work and when to use them.
Backpatch-through 10 where we have made hash indexes durable.
Author: Simon Riggs
Reviewed-By: Justin Pryzby, Amit Kapila
Discussion: https://postgr.es/m/CANbhV-HRjNPYgHo--P1ewBrFJ-GpZPb9_25P7=Wgu7s7hy_sLQ@mail.gmail.com
M doc/src/sgml/filelist.sgml
A doc/src/sgml/hash.sgml
M doc/src/sgml/postgres.sgml
doc: Mention requirement to --enable-tap-tests on section for TAP tests
commit : fb38542cd81cef535e1cc49d58feefd1a5b2bcf0
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 4 Jul 2021 20:59:19 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 4 Jul 2021 20:59:19 +0900
Author: Greg Sabino Mullane
Discussion: https://postgr.es/m/CAKAnmmJYH2FBn_+Vwd2FD5SaKn8hjhAXOCHpZc6n4wXaUaW_SA@mail.gmail.com
Backpatch-through: 9.6
M doc/src/sgml/regress.sgml
Doc: mention that VACUUM can't utilize over 1GB of RAM
commit : 4a9960e0adfe6faa692a985ae70262f6b4ad1523
author : David Rowley <drowley@postgresql.org>
date : Sun, 4 Jul 2021 22:30:35 +1200
committer: David Rowley <drowley@postgresql.org>
date : Sun, 4 Jul 2021 22:30:35 +1200
Document that setting maintenance_work_mem to values over 1GB has no
effect on VACUUM.
Reported-by: Martín Marqués
Author: Laurenz Albe
Discussion: https://postgr.es/m/CABeG9LsZ2ozUMcqtqWu_-GiFKB17ih3p8wBHXcpfnHqhCnsc7A%40mail.gmail.com
Backpatch-through: 9.6, oldest supported release
M doc/src/sgml/config.sgml
doc: adjust "cities" example to be consistent with other SQL
commit : 437d74f498c82c8a620db4991f9066a89964aa9d
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 2 Jul 2021 20:42:46 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 2 Jul 2021 20:42:46 -0400
Reported-by: tom@crystae.net
Discussion: https://postgr.es/m/162345756191.14472.9754568432103008703@wrigleys.postgresql.org
Backpatch-through: 9.6
M doc/src/sgml/advanced.sgml
Don't try to print data type names in slot_store_error_callback().
commit : feff6155734e75d9471bb84319afb6f9ca114686
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Jul 2021 16:04:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Jul 2021 16:04:54 -0400
The existing code tried to do syscache lookups in an already-failed
transaction, which is problematic to say the least. After some
consideration of alternatives, the best fix seems to be to just drop
type names from the error message altogether. The table and column
names seem like sufficient localization. If the user is unsure what
types are involved, she can check the local and remote table
definitions.
Having done that, we can also discard the LogicalRepTypMap hash
table, which had no other use. Arguably, LOGICAL_REP_MSG_TYPE
replication messages are now obsolete as well; but we should
probably keep them in case some other use emerges. (The complexity
of removing something from the replication protocol would likely
outweigh any savings anyhow.)
Masahiko Sawada and Bharath Rupireddy, per complaint from Andres
Freund. Back-patch to v10 where this code originated.
Discussion: https://postgr.es/m/20210106020229.ne5xnuu6wlondjpe@alap3.anarazel.de
M src/backend/replication/logical/relation.c
M src/backend/replication/logical/worker.c
M src/include/replication/logicalrelation.h
add missing tag from commit b8c4261e5e
commit : 383c29d1e88723638eea56091155edc6e801a778
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 1 Jul 2021 15:43:31 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 1 Jul 2021 15:43:31 -0400
M doc/src/sgml/installation.sgml
Add new make targets world-bin and install-world-bin
commit : c71471c96f1682d133dd718ed5129f0be7ebb295
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 1 Jul 2021 14:51:54 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 1 Jul 2021 14:51:54 -0400
These are the same as world and install-world respectively, but without
building or installing the documentation. There are many reasons for
wanting to be able to do this, including speed, lack of documentation
building tools, and wanting to build other formats of the documentation.
Plans for simplifying the buildfarm client code include using these
targets.
Backpatch to all live branches.
Discussion: https://postgr.es/m/6a421136-d462-b043-a8eb-e75b2861f3df@dunslane.net
M GNUmakefile.in
M doc/src/sgml/installation.sgml
Fix prove_installcheck to use correct paths when used with PGXS
commit : a40f8ea0f5550930eb743e76cb23a742f5e7befa
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 1 Jul 2021 08:29:10 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 1 Jul 2021 08:29:10 -0400
The prove_installcheck recipe in src/Makefile.global.in was emitting
bogus paths for a couple of elements when used with PGXS. Here we create
a separate recipe for the PGXS case that does it correctly. We also take
the opportunity to make the make the file more readable by breaking up
the prove_installcheck and prove_check recipes across several lines, and
to remove the setting for REGRESS_SHLIB to src/test/recovery/Makefile,
which is the only set of tests that actually need it.
Backpatch to all live branches
Discussion: https://postgr.es/m/f2401388-936b-f4ef-a07c-a0bcc49b3300@dunslane.net
M src/Makefile.global.in
M src/test/recovery/Makefile
Fix incorrect PITR message for transaction ROLLBACK PREPARED
commit : b5ee867a79b67d859b29e19ceb73300e33627074
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 30 Jun 2021 11:49:20 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 30 Jun 2021 11:49:20 +0900
Reaching PITR on such a transaction would cause the generation of a LOG
message mentioning a transaction committed, not aborted.
Oversight in 4f1b890.
Author: Simon Riggs
Discussion: https://postgr.es/m/CANbhV-GJ6KijeCgdOrxqMCQ+C8QiK657EMhCy4csjrPcEUFv_Q@mail.gmail.com
Backpatch-through: 9.6
M src/backend/access/transam/xlog.c
Don't use abort(3) in libpq's fe-print.c.
commit : 240d56fc4351a6729ec9ddf94a3d338a1e4868ab
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Jun 2021 14:17:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Jun 2021 14:17:42 -0400
Causing a core dump on out-of-memory seems pretty unfriendly,
and surely is far outside the expected behavior of a general-purpose
library. Just print an error message (as we did already) and return.
These functions unfortunately don't have an error return convention,
but code using them is probably just looking for a quick-n-dirty
print method and wouldn't bother to check anyway.
Although these functions are semi-deprecated, it still seems
appropriate to back-patch this. In passing, also back-patch
b90e6cef1, just to reduce cosmetic differences between the
branches.
Discussion: https://postgr.es/m/3122443.1624735363@sss.pgh.pa.us
M src/interfaces/libpq/fe-print.c
Don't depend on -fwrapv semantics in pgbench's random() function.
commit : 3fd334795e268ad49a48bde8fdba69b9a19f08cb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Jun 2021 12:40:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Jun 2021 12:40:37 -0400
Instead use the common/int.h functions to check for integer overflow
in a more C-standard-compliant fashion. This is motivated by recent
failures on buildfarm member moonjelly, where it appears that
development-tip gcc is optimizing without regard to the -fwrapv
switch. Presumably that's a gcc bug that will be fixed soon, but
we might as well install cleaner coding here rather than wait.
(This does not address the question of whether we'll ever be able
to get rid of using -fwrapv. Testing shows that this spot is the
only place where doing so creates visible regression test failures,
but unfortunately that proves very little.)
Back-patch to v12. The common/int.h functions exist in v11, but
that branch doesn't use them in any client-side code. I judge
that this case isn't interesting enough in the real world to take
even a small risk of issues from being the first such use.
Tom Lane and Fabien Coelho
Discussion: https://postgr.es/m/73927.1624815543@sss.pgh.pa.us
M src/bin/pgbench/pgbench.c
Fix race condition in TransactionGroupUpdateXidStatus().
commit : b75c1f6879c542c79959b42661c7f7bbf8e358be
author : Amit Kapila <akapila@postgresql.org>
date : Mon, 28 Jun 2021 08:55:47 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Mon, 28 Jun 2021 08:55:47 +0530
When we cannot immediately acquire CLogControlLock in exclusive mode at
commit time, we add ourselves to a list of processes that need their XIDs
status update. We do this if the clog page where we need to update the
current transaction status is the same as the group leader's clog page,
otherwise, we allow the caller to clear it by itself. Now, when we can't
add ourselves to any group, we were not clearing the current proc if it
has already become a member of some group which was leading to an
assertion failure when the same proc was assigned to another backend after
the current backend exits.
Reported-by: Alexander Lakhin
Bug: 17072
Author: Amit Kapila
Tested-By: Alexander Lakhin
Backpatch-through: 11, where it was introduced
Discussion: https://postgr.es/m/17072-2f8764857ef2c92a@postgresql.org
M src/backend/access/transam/clog.c
Add test for CREATE INDEX CONCURRENTLY with not-so-immutable predicate
commit : ce8949c4b6e225a3ae31e4b7ccdef0f7ab70ada6
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 28 Jun 2021 11:17:16 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 28 Jun 2021 11:17:16 +0900
83158f7 has improved index_set_state_flags() so as it is possible to use
transactional updates when updating pg_index state flags, but there was
not really a test case which stressed directly the possibility it fixed.
This commit adds such a test, using a predicate that looks valid in
appearance but calls a stable function.
Author: Andrey Lepikhov
Discussion: https://postgr.es/m/9b905019-5297-7372-0ad2-e1a4bb66a719@postgrespro.ru
Backpatch-through: 9.6
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Make index_set_state_flags() transactional
commit : e52f7cbec16ce6ccbf7f1b73a8775b42833614ce
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 28 Jun 2021 10:43:01 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 28 Jun 2021 10:43:01 +0900
3c84046 is the original commit that introduced index_set_state_flags(),
where the presence of SnapshotNow made necessary the use of an in-place
update. SnapshotNow has been removed in 813fb03, so there is no actual
reasons to not make this operation transactional.
As reported by Andrey, it is possible to trigger the assertion of this
routine expecting no transactional updates when switching the pg_index
state flags, using a predicate mark as immutable but calling stable or
volatile functions. 83158f7 has been around for a couple of months on
HEAD now with no issues found related to it, so it looks safe enough for
a backpatch.
Reported-by: Andrey Lepikhov
Author: Michael Paquier
Reviewed-by: Anastasia Lubennikova
Discussion: https://postgr.es/m/20200903080440.GA8559@paquier.xyz
Discussion: https://postgr.es/m/9b905019-5297-7372-0ad2-e1a4bb66a719@postgrespro.ru
Backpatch-through: 9.6
M src/backend/catalog/index.c
Remove memory leaks in isolationtester.
commit : bc031cf133b786ab3c3def9d28b044b85a743edc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 27 Jun 2021 12:45:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 27 Jun 2021 12:45:04 -0400
specscanner.l leaked a kilobyte of memory per token of the spec file.
Apparently somebody thought that the introductory code block would be
executed once; but it's once per yylex() call.
A couple of functions in isolationtester.c leaked small amounts of
memory due to not bothering to free one-time allocations. Might
as well improve these so that valgrind gives this program a clean
bill of health. Also get rid of an ugly static variable.
Coverity complained about one of the one-time leaks, which led me
to try valgrind'ing isolationtester, which led to discovery of the
larger leak.
M src/test/isolation/isolationtester.c
M src/test/isolation/specscanner.l
Remove some useless logs from the TAP tests of pgbench
commit : aa2734f5bcdf7d2860fb6a54104b3ed12573de83
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 26 Jun 2021 12:40:07 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 26 Jun 2021 12:40:07 +0900
002_pgbench_no_server was printing some array pointers instead of the
actual contents of those arrays for the expected outputs of stdout and
stderr for a tested command. This does not add any new information that
can help with debugging as the test names allow to track failure
locations, if any.
This commit simply removes those logs as the rest of the printed
information is redundant with command_checks_all().
Per discussion with Andrew Dunstan and Álvaro Herrera.
Discussion: https://postgr.es/m/YNXNFaG7IgkzZanD@paquier.xyz
Backpatch-through: 11
M src/bin/pgbench/t/002_pgbench_no_server.pl
Remove unnecessary failure cases in RemoveRoleFromObjectPolicy().
commit : f851696a21b2893cd927930bef10c377837c634f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Jun 2021 13:59:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Jun 2021 13:59:38 -0400
It's not really necessary for this function to open or lock the
relation associated with the pg_policy entry it's modifying. The
error checks it's making on the rel are if anything counterproductive
(e.g., if we don't want to allow installation of policies on system
catalogs, here is not the place to prevent that). In particular, it
seems just wrong to insist on an ownership check. That has the net
effect of forcing people to use superuser for DROP OWNED BY, which
surely is not an effect we want. Also there is no point in rebuilding
the dependencies of the policy expressions, which aren't being
changed. Lastly, locking the table also seems counterproductive; it's
not helping to prevent race conditions, since we failed to re-read the
pg_policy row after acquiring the lock. That means that concurrent
DDL would likely result in "tuple concurrently updated/deleted"
errors; which is the same behavior this code will produce, with less
overhead.
Per discussion of bug #17062. Back-patch to all supported versions,
as the failure cases this eliminates seem just as undesirable in 9.6
as in HEAD.
Discussion: https://postgr.es/m/1573181.1624220108@sss.pgh.pa.us
M src/backend/commands/policy.c
Make walsenders show their replication commands in pg_stat_activity.
commit : 04a47605727753de40d5ecbc4f2e7dc38577a7c2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Jun 2021 10:46:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Jun 2021 10:46:10 -0400
A walsender process that has executed a SQL command left the text of
that command in pg_stat_activity.query indefinitely, which is quite
confusing if it's in RUNNING state but not doing that query. An easy
and useful fix is to treat replication commands as if they were SQL
queries, and show them in pg_stat_activity according to the same rules
as for regular queries. While we're at it, it seems also sensible to
set debug_query_string, allowing error logging and debugging to see
the replication command.
While here, clean up assorted silliness in exec_replication_command:
* Clean up SQLCmd code path, and fix its only-accidentally-not-buggy
memory management.
* Remove useless duplicate call of SnapBuildClearExportedSnapshot().
* replication_scanner_finish() was never called.
Back-patch of commit f560209c6 into v10-v13. I'd originally felt
that this didn't merit back-patching, but subsequent confusion
while debugging walsender problems suggests that it'll be useful.
Also, the original commit has now aged long enough to provide some
comfort that it won't cause problems.
Discussion: https://postgr.es/m/2673480.1624557299@sss.pgh.pa.us
Discussion: https://postgr.es/m/880181.1600026471@sss.pgh.pa.us
M src/backend/replication/walsender.c
Cleanup some code related to pgbench log checks in TAP tests
commit : 79c24a0c21c4e6d4e62ff0a2314b6dd759c1dd37
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 25 Jun 2021 20:15:36 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 25 Jun 2021 20:15:36 +0900
This fixes a couple of problems within the so-said code of this commit
subject:
- Replace the use of open() with slurp_file(), fixing an issue reported
by buildfarm member fairywren whose perl installation keep around CRLF
characters, causing the matching patterns for the logs to fail.
- Remove the eval block, which is not really necessary.
This set of issues has come into light after fixing a different issue
with c13585fe, and this is wrong since this code has been introduced.
Reported-by: Andrew Dunstan, and buildfarm member fairywren
Author: Michael Paquier
Reviewed-by: Andrew Dunstan
Discussion: https://postgr.es/m/0f49303e-7784-b3ee-200b-cbf67be2eb9e@dunslane.net
Backpatch-through: 11
M src/bin/pgbench/t/001_pgbench_with_server.pl
Prepare for forthcoming LLVM 13 API change.
commit : 47d22649e6a233a44030ef357969ade85f3ba724
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 25 Jun 2021 09:55:26 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 25 Jun 2021 09:55:26 +1200
LLVM 13 (due out in September) has changed the semantics of
LLVMOrcAbsoluteSymbols(), so we need to bump some reference counts to
avoid a double-free that causes crashes and bad query results.
A proactive change seems necessary to avoid having a window of time
where our respective latest releases would interact badly. It's
possible that the situation could change before then, though.
Thanks to Fabien Coelho for monitoring bleeding edge LLVM and Andres
Freund for tracking down the change.
Back-patch to 11, where the JIT code arrived.
Discussion: https://postgr.es/m/CA%2BhUKGLEy8mgtN7BNp0ooFAjUedDTJj5dME7NxLU-m91b85siA%40mail.gmail.com
M src/backend/jit/llvm/llvmjit.c
Fix pattern matching logic for logs in TAP tests of pgbench
commit : 79ff96aa9d9a76cf6fd5ade9a25efb488ecd89ab
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 25 Jun 2021 06:52:52 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 25 Jun 2021 06:52:52 +0900
The logic checking for the format of per-thread logs used grep() with
directly "$re", which would cause the test to consider all the logs as
a match without caring about their format at all. Using "/$re/" makes
grep() perform a regex test, which is what we want here.
While on it, improve some of the tests to be more picky with the
patterns expected and add more comments to describe the tests.
Issue discovered while digging into a separate patch.
Author: Fabien Coelho, Michael Paquier
Discussion: https://postgr.es/m/YNPsPAUoVDCpPOGk@paquier.xyz
Backpatch-through: 11
M src/bin/pgbench/t/001_pgbench_with_server.pl
Stabilize results of insert-conflict-toast.spec.
commit : 7a48dfbb88a748c45063f46f5fa96e9a9e0fd712
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Jun 2021 11:30:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Jun 2021 11:30:32 -0400
This back-branch test script was later absorbed into
insert-conflict-specconflict.spec, which required some stabilization
in commit 741d7f104, so perhaps it's not surprising that it needs a
bit of love too.
It's odd though that we hadn't seen it fail before now, because
I thought that 741d7f104 did not change isolationtester's timing
behavior for scripts without any annotation markers. In any case,
this script is racy on its face, so add an annotation to force stable
reporting order.
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=piculet&dt=2021-06-24%2009%3A54%3A56
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=petalura&dt=2021-06-24%2010%3A10%3A00
M src/test/isolation/specs/insert-conflict-toast.spec
Fix ABI break introduced by commit 4daa140a2f.
commit : 72b51e214a2c73bf0985a049f124bb51ed973601
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 24 Jun 2021 14:53:50 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 24 Jun 2021 14:53:50 +0530
Move the newly defined enum value REORDER_BUFFER_CHANGE_INTERNAL_SPEC_ABORT
at the end to avoid ABI break in the back branches. We need to back-patch
this till v11 because before that it is already at the end.
Reported-by: Tomas Vondra
Backpatch-through: 11
Discussion: https://postgr.es/m/CAExHW5sPKF-Oovx_qZe4p5oM6Dvof7_P+XgsNAViug15Fm99jA@mail.gmail.com
M src/include/replication/reorderbuffer.h
Another fix to relmapper race condition.
commit : 8b01a403c5cc4e070107bea04e8e285151a0a073
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 24 Jun 2021 11:19:03 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 24 Jun 2021 11:19:03 +0300
In previous commit, I missed that relmap_redo() was also not acquiring the
RelationMappingLock. Thanks to Thomas Munro for pointing that out.
Backpatch-through: 9.6, like previous commit.
Discussion: https://www.postgresql.org/message-id/CA%2BhUKGLev%3DPpOSaL3WRZgOvgk217et%2BbxeJcRr4eR-NttP1F6Q%40mail.gmail.com
M src/backend/utils/cache/relmapper.c
Prevent race condition while reading relmapper file.
commit : caac1965077ffd995dfbe9facf88c05afa868c92
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 24 Jun 2021 10:45:23 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 24 Jun 2021 10:45:23 +0300
Contrary to the comment here, POSIX does not guarantee atomicity of a
read(), if another process calls write() concurrently. Or at least Linux
does not. Add locking to load_relmap_file() to avoid the race condition.
Fixes bug #17064. Thanks to Alexander Lakhin for the report and test case.
Backpatch-through: 9.6, all supported versions.
Discussion: https://www.postgresql.org/message-id/17064-bb0d7904ef72add3@postgresql.org
M src/backend/utils/cache/relmapper.c
Doc: Update caveats in synchronous logical replication.
commit : a73bd49c69e16197e8da43bc7cb17a38bd89aeee
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 24 Jun 2021 09:37:57 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 24 Jun 2021 09:37:57 +0530
Reported-by: Simon Riggs
Author: Takamichi Osumi
Reviewed-by: Amit Kapila
Backpatch-through: 9.6
Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky@alap3.anarazel.de
M doc/src/sgml/logicaldecoding.sgml
Allow non-quoted identifiers as isolation test session/step names.
commit : 35e6b3bbf745121bf7a740d57f169b0697abab99
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jun 2021 18:41:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jun 2021 18:41:39 -0400
For no obvious reason, isolationtester has always insisted that
session and step names be written with double quotes. This is
fairly tedious and does little for test readability, especially
since the names that people actually choose almost always look
like normal identifiers. Hence, let's tweak the lexer to allow
SQL-like identifiers not only double-quoted strings.
(They're SQL-like, not exactly SQL, because I didn't add any
case-folding logic. Also there's no provision for U&"..." names,
not that anyone's likely to care.)
There is one incompatibility introduced by this change: if you write
"foo""bar" with no space, that used to be taken as two identifiers,
but now it's just one identifier with an embedded quote mark.
I converted all the src/test/isolation/ specfiles to remove
unnecessary double quotes, but stopped there because my
eyes were glazing over already.
Like 741d7f104, back-patch to all supported branches, so that this
isn't a stumbling block for back-patching isolation test changes.
Discussion: https://postgr.es/m/759113.1623861959@sss.pgh.pa.us
M contrib/test_decoding/specs/oldest_xmin.spec
M src/test/isolation/README
M src/test/isolation/specparse.y
M src/test/isolation/specs/aborted-keyrevoke.spec
M src/test/isolation/specs/alter-table-1.spec
M src/test/isolation/specs/alter-table-2.spec
M src/test/isolation/specs/alter-table-3.spec
M src/test/isolation/specs/alter-table-4.spec
M src/test/isolation/specs/async-notify.spec
M src/test/isolation/specs/classroom-scheduling.spec
M src/test/isolation/specs/create-trigger.spec
M src/test/isolation/specs/deadlock-hard.spec
M src/test/isolation/specs/deadlock-simple.spec
M src/test/isolation/specs/deadlock-soft-2.spec
M src/test/isolation/specs/deadlock-soft.spec
M src/test/isolation/specs/delete-abort-savept-2.spec
M src/test/isolation/specs/delete-abort-savept.spec
M src/test/isolation/specs/drop-index-concurrently-1.spec
M src/test/isolation/specs/eval-plan-qual-trigger.spec
M src/test/isolation/specs/eval-plan-qual.spec
M src/test/isolation/specs/fk-contention.spec
M src/test/isolation/specs/fk-deadlock.spec
M src/test/isolation/specs/fk-deadlock2.spec
M src/test/isolation/specs/fk-partitioned-1.spec
M src/test/isolation/specs/fk-partitioned-2.spec
M src/test/isolation/specs/freeze-the-dead.spec
M src/test/isolation/specs/index-only-scan.spec
M src/test/isolation/specs/inherit-temp.spec
M src/test/isolation/specs/insert-conflict-do-nothing-2.spec
M src/test/isolation/specs/insert-conflict-do-nothing.spec
M src/test/isolation/specs/insert-conflict-do-update-2.spec
M src/test/isolation/specs/insert-conflict-do-update-3.spec
M src/test/isolation/specs/insert-conflict-do-update.spec
M src/test/isolation/specs/insert-conflict-specconflict.spec
M src/test/isolation/specs/insert-conflict-toast.spec
M src/test/isolation/specs/lock-committed-keyupdate.spec
M src/test/isolation/specs/lock-committed-update.spec
M src/test/isolation/specs/lock-update-delete.spec
M src/test/isolation/specs/lock-update-traversal.spec
M src/test/isolation/specs/multiple-cic.spec
M src/test/isolation/specs/multiple-row-versions.spec
M src/test/isolation/specs/multixact-no-deadlock.spec
M src/test/isolation/specs/multixact-no-forget.spec
M src/test/isolation/specs/nowait-2.spec
M src/test/isolation/specs/nowait-3.spec
M src/test/isolation/specs/nowait-4.spec
M src/test/isolation/specs/nowait-5.spec
M src/test/isolation/specs/nowait.spec
M src/test/isolation/specs/partial-index.spec
M src/test/isolation/specs/partition-concurrent-attach.spec
M src/test/isolation/specs/partition-key-update-1.spec
M src/test/isolation/specs/partition-key-update-2.spec
M src/test/isolation/specs/partition-key-update-3.spec
M src/test/isolation/specs/partition-key-update-4.spec
M src/test/isolation/specs/plpgsql-toast.spec
M src/test/isolation/specs/predicate-gin.spec
M src/test/isolation/specs/predicate-gist.spec
M src/test/isolation/specs/predicate-hash.spec
M src/test/isolation/specs/predicate-lock-hot-tuple.spec
M src/test/isolation/specs/prepared-transactions-cic.spec
M src/test/isolation/specs/prepared-transactions.spec
M src/test/isolation/specs/project-manager.spec
M src/test/isolation/specs/propagate-lock-delete.spec
M src/test/isolation/specs/read-only-anomaly-2.spec
M src/test/isolation/specs/read-only-anomaly-3.spec
M src/test/isolation/specs/read-only-anomaly.spec
M src/test/isolation/specs/read-write-unique-2.spec
M src/test/isolation/specs/read-write-unique-3.spec
M src/test/isolation/specs/read-write-unique-4.spec
M src/test/isolation/specs/read-write-unique.spec
M src/test/isolation/specs/receipt-report.spec
M src/test/isolation/specs/referential-integrity.spec
M src/test/isolation/specs/reindex-concurrently.spec
M src/test/isolation/specs/ri-trigger.spec
M src/test/isolation/specs/sequence-ddl.spec
M src/test/isolation/specs/serializable-parallel-2.spec
M src/test/isolation/specs/serializable-parallel.spec
M src/test/isolation/specs/simple-write-skew.spec
M src/test/isolation/specs/skip-locked-2.spec
M src/test/isolation/specs/skip-locked-3.spec
M src/test/isolation/specs/skip-locked-4.spec
M src/test/isolation/specs/skip-locked.spec
M src/test/isolation/specs/temporal-range-integrity.spec
M src/test/isolation/specs/timeouts.spec
M src/test/isolation/specs/total-cash.spec
M src/test/isolation/specs/truncate-conflict.spec
M src/test/isolation/specs/tuplelock-conflict.spec
M src/test/isolation/specs/tuplelock-partition.spec
M src/test/isolation/specs/tuplelock-update.spec
M src/test/isolation/specs/tuplelock-upgrade-no-deadlock.spec
M src/test/isolation/specs/two-ids.spec
M src/test/isolation/specs/update-conflict-out.spec
M src/test/isolation/specs/update-locked-tuple.spec
M src/test/isolation/specs/vacuum-concurrent-drop.spec
M src/test/isolation/specs/vacuum-conflict.spec
M src/test/isolation/specs/vacuum-reltuples.spec
M src/test/isolation/specs/vacuum-skip-locked.spec
M src/test/isolation/specscanner.l
Doc: fix confusion about LEAKPROOF in syntax summaries.
commit : 47018af55ac45046b600404c6bd9d7c7d213d037
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jun 2021 14:27:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jun 2021 14:27:13 -0400
The syntax summaries for CREATE FUNCTION and allied commands
made it look like LEAKPROOF is an alternative to
IMMUTABLE/STABLE/VOLATILE, when of course it is an orthogonal
option. Improve that.
Per gripe from aazamrafeeque0. Thanks to David Johnston for
suggestions.
Discussion: https://postgr.es/m/162444349581.694.5818572718530259025@wrigleys.postgresql.org
M doc/src/sgml/ref/alter_function.sgml
M doc/src/sgml/ref/alter_routine.sgml
M doc/src/sgml/ref/create_function.sgml
Don't assume GSSAPI result strings are null-terminated.
commit : 7eaf65451483a871056036e92e4f0fa0350b5504
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jun 2021 14:01:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jun 2021 14:01:32 -0400
Our uses of gss_display_status() and gss_display_name() assumed
that the gss_buffer_desc strings returned by those functions are
null-terminated. It appears that they generally are, given the
lack of field complaints up to now. However, the available
documentation does not promise this, and some man pages
for gss_display_status() show examples that rely on the
gss_buffer_desc.length field instead of expecting null
termination. Also, we now have a report that on some
implementations, clang's address sanitizer is of the opinion
that the byte after the specified length is undefined.
Hence, change the code to rely on the length field instead.
This might well be cosmetic rather than fixing any real bug, but
it's hard to be sure, so back-patch to all supported branches.
While here, also back-patch the v12 changes that made pg_GSS_error
deal honestly with multiple messages available from
gss_display_status.
Per report from Sudheer H R.
Discussion: https://postgr.es/m/5372B6D4-8276-42C0-B8FB-BD0918826FC3@tekenlight.com
M src/backend/libpq/auth.c
M src/backend/libpq/be-gssapi-common.c
M src/interfaces/libpq/fe-gssapi-common.c
Improve display of query results in isolation tests.
commit : d7da3ef08989691ffe13a914a839ea9e92b59a19
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jun 2021 11:12:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jun 2021 11:12:31 -0400
Previously, isolationtester displayed SQL query results using some
ad-hoc code that clearly hadn't had much effort expended on it.
Field values longer than 14 characters weren't separated from
the next field, and usually caused misalignment of the columns
too. Also there was no visual separation of a query's result
from subsequent isolationtester output. This made test result
files confusing and hard to read.
To improve matters, let's use libpq's PQprint() function. Although
that's long since unused by psql, it's still plenty good enough
for the purpose here.
Like 741d7f104, back-patch to all supported branches, so that this
isn't a stumbling block for back-patching isolation test changes.
Discussion: https://postgr.es/m/582362.1623798221@sss.pgh.pa.us
M contrib/test_decoding/expected/concurrent_ddl_dml.out
M contrib/test_decoding/expected/delayed_startup.out
M contrib/test_decoding/expected/mxact.out
M contrib/test_decoding/expected/oldest_xmin.out
M contrib/test_decoding/expected/ondisk_startup.out
M contrib/test_decoding/expected/snapshot_transfer.out
M contrib/test_decoding/expected/subxact_without_top.out
M src/test/isolation/expected/aborted-keyrevoke.out
M src/test/isolation/expected/alter-table-1.out
M src/test/isolation/expected/alter-table-2.out
M src/test/isolation/expected/alter-table-3.out
M src/test/isolation/expected/alter-table-4.out
M src/test/isolation/expected/async-notify.out
M src/test/isolation/expected/classroom-scheduling.out
M src/test/isolation/expected/create-trigger.out
M src/test/isolation/expected/delete-abort-savept-2.out
M src/test/isolation/expected/delete-abort-savept.out
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/expected/eval-plan-qual-trigger.out
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/expected/fk-partitioned-2.out
M src/test/isolation/expected/freeze-the-dead.out
M src/test/isolation/expected/inherit-temp.out
M src/test/isolation/expected/insert-conflict-do-nothing-2.out
M src/test/isolation/expected/insert-conflict-do-nothing.out
M src/test/isolation/expected/insert-conflict-do-update-2.out
M src/test/isolation/expected/insert-conflict-do-update-3.out
M src/test/isolation/expected/insert-conflict-do-update.out
M src/test/isolation/expected/insert-conflict-specconflict.out
M src/test/isolation/expected/insert-conflict-toast.out
M src/test/isolation/expected/lock-committed-keyupdate.out
M src/test/isolation/expected/lock-committed-update.out
M src/test/isolation/expected/lock-update-delete.out
M src/test/isolation/expected/lock-update-delete_1.out
M src/test/isolation/expected/lock-update-traversal.out
M src/test/isolation/expected/multiple-cic.out
M src/test/isolation/expected/multiple-row-versions.out
M src/test/isolation/expected/multixact-no-deadlock.out
M src/test/isolation/expected/multixact-no-forget.out
M src/test/isolation/expected/multixact-no-forget_1.out
M src/test/isolation/expected/nowait-2.out
M src/test/isolation/expected/nowait-3.out
M src/test/isolation/expected/nowait-4.out
M src/test/isolation/expected/nowait-4_1.out
M src/test/isolation/expected/nowait-5.out
M src/test/isolation/expected/nowait.out
M src/test/isolation/expected/partial-index.out
M src/test/isolation/expected/partition-concurrent-attach.out
M src/test/isolation/expected/partition-key-update-2.out
M src/test/isolation/expected/partition-key-update-3.out
M src/test/isolation/expected/partition-key-update-4.out
M src/test/isolation/expected/plpgsql-toast.out
M src/test/isolation/expected/predicate-gin.out
M src/test/isolation/expected/predicate-gist.out
M src/test/isolation/expected/predicate-hash.out
M src/test/isolation/expected/predicate-lock-hot-tuple.out
M src/test/isolation/expected/prepared-transactions-cic.out
M src/test/isolation/expected/prepared-transactions.out
M src/test/isolation/expected/project-manager.out
M src/test/isolation/expected/read-only-anomaly-2.out
M src/test/isolation/expected/read-only-anomaly-3.out
M src/test/isolation/expected/read-only-anomaly.out
M src/test/isolation/expected/read-write-unique-2.out
M src/test/isolation/expected/read-write-unique-3.out
M src/test/isolation/expected/read-write-unique-4.out
M src/test/isolation/expected/read-write-unique.out
M src/test/isolation/expected/receipt-report.out
M src/test/isolation/expected/referential-integrity.out
M src/test/isolation/expected/reindex-concurrently.out
M src/test/isolation/expected/ri-trigger.out
M src/test/isolation/expected/sequence-ddl.out
M src/test/isolation/expected/serializable-parallel-2.out
M src/test/isolation/expected/serializable-parallel.out
M src/test/isolation/expected/skip-locked-2.out
M src/test/isolation/expected/skip-locked-3.out
M src/test/isolation/expected/skip-locked-4.out
M src/test/isolation/expected/skip-locked-4_1.out
M src/test/isolation/expected/skip-locked.out
M src/test/isolation/expected/temporal-range-integrity.out
M src/test/isolation/expected/timeouts.out
M src/test/isolation/expected/total-cash.out
M src/test/isolation/expected/truncate-conflict.out
M src/test/isolation/expected/tuplelock-conflict.out
M src/test/isolation/expected/tuplelock-partition.out
M src/test/isolation/expected/tuplelock-update.out
M src/test/isolation/expected/tuplelock-upgrade-no-deadlock.out
M src/test/isolation/expected/two-ids.out
M src/test/isolation/expected/update-conflict-out.out
M src/test/isolation/expected/vacuum-reltuples.out
M src/test/isolation/isolationtester.c
M src/test/modules/brin/expected/summarization-and-inprogress-insertion.out
M src/test/modules/snapshot_too_old/expected/sto_using_cursor.out
M src/test/modules/snapshot_too_old/expected/sto_using_hash_index.out
M src/test/modules/snapshot_too_old/expected/sto_using_select.out
Use annotations to reduce instability of isolation-test results.
commit : f228c401b86bd68570c9d8f6348bc0a4e66b2325
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Jun 2021 21:43:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Jun 2021 21:43:12 -0400
We've long contended with isolation test results that aren't entirely
stable. Some test scripts insert long delays to try to force stable
results, which is not terribly desirable; but other erratic failure
modes remain, causing unrepeatable buildfarm failures. I've spent a
fair amount of time trying to solve this by improving the server-side
support code, without much success: that way is fundamentally unable
to cope with diffs that stem from chance ordering of arrival of
messages from different server processes.
We can improve matters on the client side, however, by annotating
the test scripts themselves to show the desired reporting order
of events that might occur in different orders. This patch adds
three types of annotations to deal with (a) test steps that might or
might not complete their waits before the isolationtester can see them
waiting; (b) test steps in different sessions that can legitimately
complete in either order; and (c) NOTIFY messages that might arrive
before or after the completion of a step in another session. We might
need more annotation types later, but this seems to be enough to deal
with the instabilities we've seen in the buildfarm. It also lets us
get rid of all the long delays that were previously used, cutting more
than a minute off the runtime of the isolation tests.
Back-patch to all supported branches, because the buildfarm
instabilities affect all the branches, and because it seems desirable
to keep isolationtester's capabilities the same across all branches
to simplify possible future back-patching of tests.
Discussion: https://postgr.es/m/327948.1623725828@sss.pgh.pa.us
M contrib/test_decoding/expected/concurrent_ddl_dml.out
M src/test/isolation/README
M src/test/isolation/expected/alter-table-3.out
M src/test/isolation/expected/alter-table-4.out
M src/test/isolation/expected/deadlock-hard.out
M src/test/isolation/expected/deadlock-simple.out
M src/test/isolation/expected/eval-plan-qual-trigger.out
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/expected/fk-deadlock2_1.out
M src/test/isolation/expected/fk-deadlock2_2.out
M src/test/isolation/expected/fk-deadlock_1.out
M src/test/isolation/expected/fk-partitioned-1.out
M src/test/isolation/expected/fk-partitioned-2.out
M src/test/isolation/expected/insert-conflict-do-nothing-2.out
M src/test/isolation/expected/lock-committed-keyupdate.out
M src/test/isolation/expected/lock-update-delete_1.out
M src/test/isolation/expected/multiple-cic.out
D src/test/isolation/expected/multiple-cic_1.out
M src/test/isolation/expected/multixact-no-forget_1.out
M src/test/isolation/expected/nowait-4.out
M src/test/isolation/expected/nowait-4_1.out
M src/test/isolation/expected/nowait-5.out
M src/test/isolation/expected/partition-concurrent-attach.out
M src/test/isolation/expected/partition-key-update-1.out
M src/test/isolation/expected/partition-key-update-3.out
M src/test/isolation/expected/propagate-lock-delete.out
M src/test/isolation/expected/read-write-unique-2.out
M src/test/isolation/expected/read-write-unique-3.out
M src/test/isolation/expected/read-write-unique-4.out
M src/test/isolation/expected/read-write-unique.out
M src/test/isolation/expected/sequence-ddl.out
M src/test/isolation/expected/skip-locked-4_1.out
M src/test/isolation/expected/timeouts.out
M src/test/isolation/expected/tuplelock-update.out
M src/test/isolation/isolationtester.c
M src/test/isolation/isolationtester.h
M src/test/isolation/specparse.y
M src/test/isolation/specs/deadlock-hard.spec
M src/test/isolation/specs/deadlock-soft-2.spec
M src/test/isolation/specs/multiple-cic.spec
M src/test/isolation/specs/timeouts.spec
M src/test/isolation/specs/tuplelock-update.spec
M src/test/isolation/specscanner.l
Restore the portal-level snapshot for simple expressions, too.
commit : 29d5d5761aa8695e1226f1f76b7f76a2a4b195a0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Jun 2021 17:48:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Jun 2021 17:48:39 -0400
Commits 84f5c2908 et al missed the need to cover plpgsql's "simple
expression" code path. If the first thing we execute after a
COMMIT/ROLLBACK is one of those, rather than a full-fledged SPI command,
we must explicitly do EnsurePortalSnapshotExists() to make sure we have
an outer snapshot. Note that it wouldn't be good enough to just push a
snapshot for the duration of the expression execution: what comes back
might be toasted, so we'd better have a snapshot protecting it.
The test case demonstrating this fact cheats a bit by marking a SQL
function immutable even though it fetches from a table. That's
nothing that users haven't been seen to do, though.
Per report from Jim Nasby. Back-patch to v11, like the previous fix.
Discussion: https://postgr.es/m/378885e4-f85f-fc28-6c91-c4d1c080bf26@amazon.com
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql
Fix misbehavior of DROP OWNED BY with duplicate polroles entries.
commit : c58a41605ffabe8e4184b4c3b2d919638cd3357d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Jun 2021 18:00:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Jun 2021 18:00:09 -0400
Ordinarily, a pg_policy.polroles array wouldn't list the same role
more than once; but CREATE POLICY does not prevent that. If we
perform DROP OWNED BY on a role that is listed more than once,
RemoveRoleFromObjectPolicy either suffered an assertion failure
or encountered a tuple-updated-by-self error. Rewrite it to cope
correctly with duplicate entries, and add a CommandCounterIncrement
call to prevent the other problem.
Per discussion, there's other cleanup that ought to happen here,
but this seems like the minimum essential fix.
Per bug #17062 from Alexander Lakhin. It's been broken all along,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/17062-11f471ae3199ca23@postgresql.org
M src/backend/commands/policy.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Avoid scribbling on input node tree in CREATE/ALTER DOMAIN.
commit : b2c740c426daca2e43a2c86ff19661baf05ad00a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Jun 2021 12:09:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Jun 2021 12:09:22 -0400
This works fine in the "simple Query" code path; but if the
statement is in the plan cache then it's corrupted for future
re-execution. Apply copyObject() to protect the original
tree from modification, as we've done elsewhere.
This narrow fix is applied only to the back branches. In HEAD,
the problem was fixed more generally by commit 7c337b6b5; but
that changed ProcessUtility's API, so it's infeasible to
back-patch.
Per bug #17053 from Charles Samborski.
Discussion: https://postgr.es/m/931771.1623893989@sss.pgh.pa.us
Discussion: https://postgr.es/m/17053-3ca3f501bbc212b4@postgresql.org
M src/backend/commands/typecmds.c
Don't set a fast default for anything but a plain table
commit : 6432bfe8a372a1c1d4ee8edc91be7fe9910bf51d
author : Andrew Dunstan <andrew@dunslane.net>
date : Fri, 18 Jun 2021 07:44:58 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Fri, 18 Jun 2021 07:44:58 -0400
The fast default code added in Release 11 omitted to check that the
table a fast default was being added to was a plain table. Thus one
could be added to a foreign table, which predicably blows up. Here we
perform that check.
In addition, on the back branches, since some of these might have
escaped into the wild, if we encounter a missing value for
an attribute of something other than a plain table we ignore it.
Fixes bug #17056
Backpatch to release 11,
Reviewed by: Andres Freund, Álvaro Herrera and Tom Lane
M src/backend/catalog/heap.c
M src/backend/commands/tablecmds.c
M src/backend/utils/cache/relcache.c
M src/test/regress/expected/fast_default.out
M src/test/regress/sql/fast_default.sql
Update plpython_subtransaction alternative expected files
commit : 70293e946e60bb7eb58f74656667458406a1b461
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 17 Jun 2021 16:37:13 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 17 Jun 2021 16:37:13 +0200
The original patch only targeted Python 2.6 and newer, since that is
what we have supported in PostgreSQL 13 and newer. For older
branches, we need to fix it up for older Python versions.
M src/pl/plpython/expected/plpython_subtransaction.out
M src/pl/plpython/expected/plpython_subtransaction_0.out
M src/pl/plpython/expected/plpython_subtransaction_5.out
M src/pl/plpython/sql/plpython_subtransaction.sql
Tidy up GetMultiXactIdMembers()'s behavior on error
commit : 6765cbd22a6bf1d11f4293fe7daed7512fb54ecf
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 17 Jun 2021 14:50:42 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 17 Jun 2021 14:50:42 +0300
One of the error paths left *members uninitialized. That's not a live
bug, because most callers don't look at *members when the function
returns -1, but let's be tidy. One caller, in heap_lock_tuple(), does
"if (members != NULL) pfree(members)", but AFAICS it never passes an
invalid 'multi' value so it should not reach that error case.
The callers are also a bit inconsistent in their expectations.
heap_lock_tuple() pfrees the 'members' array if it's not-NULL, others
pfree() it if "nmembers >= 0", and others if "nmembers > 0". That's
not a live bug either, because the function should never return 0, but
add an Assert for that to make it more clear. I left the callers alone
for now.
I also moved the line where we set *nmembers. It wasn't wrong before,
but I like to do that right next to the 'return' statement, to make it
clear that it's always set on return.
Also remove one unreachable return statement after ereport(ERROR), for
brevity and for consistency with the similar if-block right after it.
Author: Greg Nancarrow with the additional changes by me
Backpatch-through: 9.6, all supported versions
M src/backend/access/transam/multixact.c
Fix subtransaction test for Python 3.10
commit : 9438962ce32fd2fa437b5a447c40c5dac2ef9f08
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 5 Jun 2021 07:16:34 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 5 Jun 2021 07:16:34 +0200
Starting with Python 3.10, the stacktrace looks differently:
- PL/Python function "subtransaction_exit_subtransaction_in_with", line 3, in <module>
- s.__exit__(None, None, None)
+ PL/Python function "subtransaction_exit_subtransaction_in_with", line 2, in <module>
+ with plpy.subtransaction() as s:
Using try/except specifically makes the error look always the same.
(See https://github.com/python/cpython/pull/25719 for the discussion
of this change in Python.)
Author: Honza Horak <hhorak@redhat.com>
Discussion: https://www.postgresql.org/message-id/flat/853083.1620749597%40sss.pgh.pa.us
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1959080
M src/pl/plpython/expected/plpython_subtransaction.out
M src/pl/plpython/sql/plpython_subtransaction.sql
Document a few caveats in synchronous logical replication.
commit : eb231dbd80d2318e27e9b4d0aa72696de6e6b32f
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 17 Jun 2021 10:40:56 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 17 Jun 2021 10:40:56 +0530
In a synchronous logical setup, locking [user] catalog tables can cause
deadlock. This is because logical decoding of transactions can lock
catalog tables to access them so exclusively locking those in transactions
can lead to deadlock. To avoid this users must refrain from having
exclusive locks on catalog tables.
Author: Takamichi Osumi
Reviewed-by: Vignesh C, Amit Kapila
Backpatch-through: 9.6
Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky%40alap3.anarazel.de
M doc/src/sgml/logicaldecoding.sgml
Detect unused steps in isolation specs and do some cleanup
commit : 96f3661e4540db1f45709c5f098aeecc6e9df271
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 17 Jun 2021 11:57:21 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 17 Jun 2021 11:57:21 +0900
This is useful for developers to find out if an isolation spec is
over-engineered or if it needs more work by warning at the end of a
test run if a step is not used, generating a failure with extra diffs.
While on it, clean up all the specs which include steps not used in any
permutations to simplify them.
This is a backpatch of 989d23b and 06fdc4e, as it is becoming useful to
make all the branches consistent for an upcoming patch that will improve
the output generated by isolationtester.
Author: Michael Paquier
Reviewed-by: Asim Praveen, Melanie Plageman
Discussion: https://postgr.es/m/20190819080820.GG18166@paquier.xyz
Discussion: https://postgr.es/m/794820.1623872009@sss.pgh.pa.us
Backpatch-through: 9.6
M contrib/test_decoding/specs/concurrent_ddl_dml.spec
M contrib/test_decoding/specs/snapshot_transfer.spec
M src/test/isolation/expected/eval-plan-qual-trigger.out
M src/test/isolation/isolationtester.c
M src/test/isolation/isolationtester.h
M src/test/isolation/specparse.y
M src/test/isolation/specs/eval-plan-qual-trigger.spec
M src/test/isolation/specs/freeze-the-dead.spec
M src/test/isolation/specs/insert-conflict-do-nothing.spec
M src/test/isolation/specs/insert-conflict-do-update-2.spec
M src/test/isolation/specs/insert-conflict-do-update.spec
M src/test/isolation/specs/sequence-ddl.spec
M src/test/isolation/specs/tuplelock-upgrade-no-deadlock.spec
Remove dry-run mode from isolationtester
commit : a8f687927eea873031f3a8e2e658ad40359617b1
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 17 Jun 2021 11:01:16 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 17 Jun 2021 11:01:16 +0900
The original purpose of the dry-run mode is to be able to print all the
possible permutations from a spec file, but it has become less useful
since isolation tests have improved regarding deadlock detection as one
step not wanted by the author could block indefinitely now (originally
the step blocked would have been detected rather quickly). Per
discussion, let's remove it.
This is a backpatch of 9903338 for 9.6~12. It is proving to become
useful to have on those branches so as the code gets consistent across
all supported versions, as a matter of improving the output generated by
isolationtester.
Author: Michael Paquier
Reviewed-by: Asim Praveen, Melanie Plageman
Discussion: https://postgr.es/m/20190819080820.GG18166@paquier.xyz
Discussion: https://postgr.es/m/794820.1623872009@sss.pgh.pa.us
Backpatch-through: 9.6
M src/test/isolation/isolationtester.c
Fix plancache refcount leak after error in ExecuteQuery.
commit : 17d962ccae33db4526d08f909eea536a2a2383cf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Jun 2021 19:30:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Jun 2021 19:30:17 -0400
When stuffing a plan from the plancache into a Portal, one is
not supposed to risk throwing an error between GetCachedPlan and
PortalDefineQuery; if that happens, the plan refcount incremented
by GetCachedPlan will be leaked. I managed to break this rule
while refactoring code in 9dbf2b7d7. There is no visible
consequence other than some memory leakage, and since nobody is
very likely to trigger the relevant error conditions many times
in a row, it's not surprising we haven't noticed. Nonetheless,
it's a bug, so rearrange the order of operations to remove the
hazard.
Noted on the way to looking for a better fix for bug #17053.
This mistake is pretty old, so back-patch to all supported
branches.
M src/backend/commands/prepare.c
Fix outdated comment that talked about seek position of WAL file.
commit : f98635ad6295ad142779756e60325a8e7f825909
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 16 Jun 2021 12:34:32 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 16 Jun 2021 12:34:32 +0300
Since commit c24dcd0cfd, we have been using pg_pread() to read the WAL
file, which doesn't change the seek position (unless we fall back to
the implementation in src/port/pread.c). Update comment accordingly.
Backpatch-through: 12, where we started to use pg_pread()
M src/backend/access/transam/xlog.c
Further refinement of stuck_on_old_timeline recovery test
commit : fb3d6b0e1aa41518857ff12534bef49503ce7575
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 15 Jun 2021 15:30:11 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 15 Jun 2021 15:30:11 -0400
TestLib::perl2host can take a file argument as well as a directory
argument, so that code becomes substantially simpler. Also add comments
on why we're using forward slashes, and why we're setting
PERL_BADLANG=0.
Discussion: https://postgr.es/m/e9947bcd-20ee-027c-f0fe-01f736b7e345@dunslane.net
M src/test/recovery/t/025_stuck_on_old_timeline.pl
Fix decoding of speculative aborts.
commit : 40ad7ebff6ca08a67f11108e73f6563416c8603b
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 15 Jun 2021 08:50:12 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 15 Jun 2021 08:50:12 +0530
During decoding for speculative inserts, we were relying for cleaning
toast hash on confirmation records or next change records. But that
could lead to multiple problems (a) memory leak if there is neither a
confirmation record nor any other record after toast insertion for a
speculative insert in the transaction, (b) error and assertion failures
if the next operation is not an insert/update on the same table.
The fix is to start queuing spec abort change and clean up toast hash
and change record during its processing. Currently, we are queuing the
spec aborts for both toast and main table even though we perform cleanup
while processing the main table's spec abort record. Later, if we have a
way to distinguish between the spec abort record of toast and the main
table, we can avoid queuing the change for spec aborts of toast tables.
Reported-by: Ashutosh Bapat
Author: Dilip Kumar
Reviewed-by: Amit Kapila
Backpatch-through: 9.6, where it was introduced
Discussion: https://postgr.es/m/CAExHW5sPKF-Oovx_qZe4p5oM6Dvof7_P+XgsNAViug15Fm99jA@mail.gmail.com
M src/backend/replication/logical/decode.c
M src/backend/replication/logical/reorderbuffer.c
M src/include/replication/reorderbuffer.h
Work around portability issue with newer versions of mktime().
commit : b7c5823ac31664149453607a51ddf78d05383e4f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Jun 2021 14:32:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Jun 2021 14:32:42 -0400
Recent glibc versions have made mktime() fail if tm_isdst is
inconsistent with the prevailing timezone; in particular it fails for
tm_isdst = 1 when the zone is UTC. (This seems wildly inconsistent
with the POSIX-mandated treatment of "incorrect" values for the other
fields of struct tm, so if you ask me it's a bug, but I bet they'll
say it's intentional.) This has been observed to cause cosmetic
problems when pg_restore'ing an archive created in a different
timezone.
To fix, do mktime() using the field values from the archive, and if
that fails try again with tm_isdst = -1. This will give a result
that's off by the UTC-offset difference from the original zone, but
that was true before, too. It's not terribly critical since we don't
do anything with the result except possibly print it. (Someday we
should flush this entire bit of logic and record a standard-format
timestamp in the archive instead. That's not okay for a back-patched
bug fix, though.)
Also, guard our only other use of mktime() by having initdb's
build_time_t() set tm_isdst = -1 not 0. This case could only have
an issue in zones that are DST year-round; but I think some do exist,
or could in future.
Per report from Wells Oliver. Back-patch to all supported
versions, since any of them might need to run with a newer glibc.
Discussion: https://postgr.es/m/CAOC+FBWDhDHO7G-i1_n_hjRzCnUeFO+H-Czi1y10mFhRWpBrew@mail.gmail.com
M src/bin/initdb/findtimezone.c
M src/bin/pg_dump/pg_backup_archiver.c
Further tweaks to stuck_on_old_timeline recovery test
commit : 914c716ca02ac576d7f4db6c69b26cb042512a84
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 13 Jun 2021 07:10:41 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 13 Jun 2021 07:10:41 -0400
Translate path slashes on target directory path. This was confusing old
branches, but is applied to all branches for the sake of uniformity.
Perl is perfectly able to understand paths with forward slashes.
Along the way, restore the previous archive_wait query, for the sake of
uniformity with other tests, per gripe from Tom Lane.
M src/test/recovery/t/025_stuck_on_old_timeline.pl
Ignore more environment variables in pg_regress.c
commit : 37d4edef00e40085f31bfd578b07c5e319e9818a
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 13 Jun 2021 20:07:50 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 13 Jun 2021 20:07:50 +0900
This is similar to the work done in 8279f68 for TestLib.pm, where
environment variables set may cause unwanted failures if using a
temporary installation with pg_regress. The list of variables reset is
adjusted in each stable branch depending on what is supported.
Comments are added to remember that the lists in TestLib.pm and
pg_regress.c had better be kept in sync.
Reviewed-by: Álvaro Herrera
Discussion: https://postgr.es/m/YMNR9GYDn+fHlMta@paquier.xyz
Backpatch-through: 9.6
M src/test/perl/TestLib.pm
M src/test/regress/pg_regress.c
Restore robustness of TAP tests that wait for postmaster restart.
commit : 0b619df6daca4ed895b25dad6b4297f33fdc4a00
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Jun 2021 15:12:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Jun 2021 15:12:10 -0400
Several TAP tests use poll_query_until() to wait for the postmaster
to restart. They were checking to see if a trivial query
(e.g. "SELECT 1") succeeds. However, that's problematic in the wake
of commit 11e9caff8, because now that we feed said query to psql
via stdin, we risk IPC::Run whining about a SIGPIPE failure if psql
quits before reading the query. Hence, we can't use a nonempty
query in cases where we need to wait for connection failures to
stop happening.
Per the precedent of commits c757a3da0 and 6d41dd045, we can pass
"undef" as the query in such cases to ensure that IPC::Run has
nothing to write. However, then we have to say that the expected
output is empty, and this exposes a deficiency in poll_query_until:
if psql fails altogether and returns empty stdout, poll_query_until
will treat that as a success! That's because, contrary to its
documentation, it makes no actual check for psql failure, looking
neither at the exit status nor at stderr.
To fix that, adjust poll_query_until to insist on empty stderr as
well as a stdout match. (I experimented with checking exit status
instead, but it seems that psql often does exit(1) in cases that we
need to consider successes. That might be something to fix someday,
but it would be a non-back-patchable behavior change.)
Back-patch to v10. The test cases needing this exist only as far
back as v11, but it seems wise to keep poll_query_until's behavior
the same in v10, in case we back-patch another such test case in
future. (9.6 does not currently need this change, because in that
branch poll_query_until can't be told to accept empty stdout as
a success case.)
Per assorted buildfarm failures, mostly on hoverfly.
Discussion: https://postgr.es/m/CAA4eK1+zM6L4QSA1XMvXY_qqWwdUmqkOS1+hWvL8QcYEBGA1Uw@mail.gmail.com
M src/test/perl/PostgresNode.pm
M src/test/recovery/t/013_crash_restart.pl
Ensure pg_filenode_relation(0, 0) returns NULL.
commit : 7681b78fba106b43d9b10d22b52ba2d5cbfc1326
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Jun 2021 13:29:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Jun 2021 13:29:24 -0400
Previously, a zero value for the relfilenode resulted in
a confusing error message about "unexpected duplicate".
This function returns NULL for other invalid relfilenode
values, so zero should be treated likewise.
It's been like this all along, so back-patch to all supported
branches.
Justin Pryzby
Discussion: https://postgr.es/m/20210612023324.GT16435@telsasoft.com
M src/backend/utils/adt/dbsize.c
Don't use Asserts to check for violations of replication protocol.
commit : 1f280e83314f6000b89046adc786f680e18d902f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Jun 2021 12:59:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Jun 2021 12:59:15 -0400
Using an Assert to check the validity of incoming messages is an
extremely poor decision. In a debug build, it should not be that easy
for a broken or malicious remote client to crash the logrep worker.
The consequences could be even worse in non-debug builds, which will
fail to make such checks at all, leading to who-knows-what misbehavior.
Hence, promote every Assert that could possibly be triggered by wrong
or out-of-order replication messages to a full test-and-ereport.
To avoid bloating the set of messages the translation team has to cope
with, establish a policy that replication protocol violation error
reports don't need to be translated. Hence, all the new messages here
use errmsg_internal(). A couple of old messages are changed likewise
for consistency.
Along the way, fix some non-idiomatic or outright wrong uses of
hash_search().
Most of these mistakes are new with the "streaming replication"
patch (commit 464824323), but a couple go back a long way.
Back-patch as appropriate.
Discussion: https://postgr.es/m/1719083.1623351052@sss.pgh.pa.us
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/worker.c
Fix new recovery test for use under msys
commit : 1730a3334e4a791b88cfc39bd45bee5a0d7b817c
author : Andrew Dunstan <andrew@dunslane.net>
date : Sat, 12 Jun 2021 08:37:16 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sat, 12 Jun 2021 08:37:16 -0400
Commit caba8f0d43 wasn't quite right for msys, as demonstrated by
several buildfarm animals, including jacana and fairywren. We need to
use the msys perl in the archive command, but call it in such a way that
Windows will understand the path. Furthermore, inside the copy script we
need to convert a Windows path to an msys path.
M src/test/recovery/t/025_stuck_on_old_timeline.pl
M src/test/recovery/t/cp_history_files
Remove PGSSLCRLDIR from the list of variables ignored in TAP tests
commit : b56ef31bf946337a47a797250a3d8b6ca22cbade
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 12 Jun 2021 10:39:28 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 12 Jun 2021 10:39:28 +0900
This variable was present in the list added by 9d660670, but it is not
supported by this branch. Issue noticed while diving into a similar
change for pg_regress.c.
Backpatch-through: 9.6
M src/test/perl/TestLib.pm
Report sort phase progress in parallel btree build
commit : 0c7efd975754b41bccabbb55902b6d79bd350515
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 11 Jun 2021 19:07:32 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 11 Jun 2021 19:07:32 -0400
We were already reporting it, but only after the parallel workers were
finished, which is visibly much later than what happens in a serial
build.
With this change we report it when the leader starts its own sort phase
when participating in the build (the normal case). Now this might
happen a little later than when the workers start their sorting phases,
but a) communicating the actual phase start from workers is likely to be
a hassle, and b) the sort phase start is pretty fuzzy anyway, since
sorting per se is actually initiated by tuplesort.c internally earlier
than tuplesort_performsort() is called.
Backpatch to pg12, where the progress reporting code for CREATE INDEX
went in.
Reported-by: Tomas Vondra <tomas.vondra@enterprisedb.com>
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>
Reviewed-by: Greg Nancarrow <gregn4422@gmail.com>
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/1128176d-1eee-55d4-37ca-e63644422adb
M src/backend/access/nbtree/nbtsort.c
Rearrange logrep worker's snapshot handling some more.
commit : 26383da7d47a140c33271bfd9215fe50959c80e3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Jun 2021 12:27:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Jun 2021 12:27:27 -0400
It turns out that worker.c's code path for TRUNCATE was also
careless about establishing a snapshot while executing user-defined
code, allowing the checks added by commit 84f5c2908 to fail when
a trigger is fired in that context.
We could just wrap Push/PopActiveSnapshot around the truncate call,
but it seems better to establish a policy of holding a snapshot
throughout execution of a replication step. To help with that and
possible future requirements, replace the previous ensure_transaction
calls with pairs of begin/end_replication_step calls.
Per report from Mark Dilger. Back-patch to v11, like the previous
changes.
Discussion: https://postgr.es/m/B4A3AF82-79ED-4F4C-A4E5-CD2622098972@enterprisedb.com
M src/backend/replication/logical/worker.c
Adjust new test case to set wal_keep_segments.
commit : 2208d71a0099bf51c70e1636e10a3e7dffe6581f
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 10 Jun 2021 09:34:39 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 10 Jun 2021 09:34:39 -0400
Per buildfarm member conchuela and Kyotaro Horiguchi, it's possible
for the WAL segment that the cascading standby needs to be removed
too quickly. Hopefully this will prevent that.
Kyotaro Horiguchi
Discussion: http://postgr.es/m/20210610.101240.1270925505780628275.horikyota.ntt@gmail.com
M src/test/recovery/t/025_stuck_on_old_timeline.pl
Fix corner case failure of new standby to follow new primary.
commit : 5d950c721d38ff81913ecae6f75d5ccea904bd8e
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 9 Jun 2021 16:19:52 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 9 Jun 2021 16:19:52 -0400
This only happens if (1) the new standby has no WAL available locally,
(2) the new standby is starting from the old timeline, (3) the promotion
happened in the WAL segment from which the new standby is starting,
(4) the timeline history file for the new timeline is available from
the archive but the WAL files for are not (i.e. this is a race),
(5) the WAL files for the new timeline are available via streaming,
and (6) recovery_target_timeline='latest'.
Commit ee994272ca50f70b53074f0febaec97e28f83c4e introduced this
logic and was an improvement over the previous code, but it mishandled
this case. If recovery_target_timeline='latest' and restore_command is
set, validateRecoveryParameters() can change recoveryTargetTLI to be
different from receiveTLI. If streaming is then tried afterward,
expectedTLEs gets initialized with the history of the wrong timeline.
It's supposed to be a list of entries explaining how to get to the
target timeline, but in this case it ends up with a list of entries
explaining how to get to the new standby's original timeline, which
isn't right.
Dilip Kumar and Robert Haas, reviewed by Kyotaro Horiguchi.
Discussion: http://postgr.es/m/CAFiTN-sE-jr=LB8jQuxeqikd-Ux+jHiXyh4YDiZMPedgQKup0g@mail.gmail.com
M src/backend/access/transam/xlog.c
A src/test/recovery/t/025_stuck_on_old_timeline.pl
A src/test/recovery/t/cp_history_files
Allow PostgresNode.pm's backup method to accept backup_options.
commit : 6fc2febc28ae36d906b144af82773bc2f8040b7e
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 9 Jun 2021 12:29:00 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 9 Jun 2021 12:29:00 -0400
Partial back-port of commit 081876d75ea15c3bd2ee5ba64a794fd8ea46d794.
A test case for a pending bug fix needs this capability, but the code
on 9.6 is significantly different, so I'm only back-patching this
change as far as v10. We'll have to work around the problem another
way in v9.6.
Discussion: http://postgr.es/m/CAFiTN-tcivNvL0Rg6rD7_CErNfE75H7+gh9WbMxjbgsattja1Q@mail.gmail.com
M src/test/perl/PostgresNode.pm
Fix inconsistencies in psql --help=commands
commit : 01e9e935a1df1e4f77d4490e1986b15b0ddff064
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 9 Jun 2021 16:25:57 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 9 Jun 2021 16:25:57 +0900
The set of subcommands supported by \dAp, \do and \dy was described
incorrectly in psql's --help. The documentation was already consistent
with the code.
Reported-by: inoas, from IRC
Author: Matthijs van der Vleuten
Reviewed-by: Neil Chen
Discussion: https://postgr.es/m/6a984e24-2171-4039-9050-92d55e7b23fe@www.fastmail.com
Backpatch-through: 9.6
M src/bin/psql/help.c
Force NO SCROLL for plpgsql's implicit cursors.
commit : 18232330062026d3575ec5f387b70f63a856e0ea
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Jun 2021 18:40:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Jun 2021 18:40:06 -0400
Further thought about bug #17050 suggests that it's a good idea
to use CURSOR_OPT_NO_SCROLL for the implicit cursor opened by
a plpgsql FOR-over-query loop. This ensures that, if somebody
commits inside the loop, PersistHoldablePortal won't try to
rewind and re-read the cursor. While we'd have selected NO_SCROLL
anyway if FOR UPDATE/SHARE appears in the query, there are other
hazards with volatile functions; and in any case, it's silly to
expend effort storing rows that we know for certain won't be needed.
(While here, improve the comment in exec_run_select, which was a bit
confused about the rationale for when we can use parallel mode.
Cursor operations aren't a hazard for nameless portals.)
This wasn't an issue until v11, which introduced the possibility
of persisting such cursors. Hence, back-patch to v11.
Per bug #17050 from Алексей Булгаков.
Discussion: https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org
M src/pl/plpgsql/src/pl_exec.c
Avoid misbehavior when persisting a non-stable cursor.
commit : c3b5082685dd6f9f6b76c227e04ae8dca720acc5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Jun 2021 17:50:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Jun 2021 17:50:15 -0400
PersistHoldablePortal has long assumed that it should store the
entire output of the query-to-be-persisted, which requires rewinding
and re-reading the output. This is problematic if the query is not
stable: we might get different row contents, or even a different
number of rows, which'd confuse the cursor state mightily.
In the case where the cursor is NO SCROLL, this is very easy to
solve: just store the remaining query output, without any rewinding,
and tweak the portal's cursor state to match. Aside from removing
the semantic problem, this could be significantly more efficient
than storing the whole output.
If the cursor is scrollable, there's not much we can do, but it
was already the case that scrolling a volatile query's result was
pretty unsafe. We can just document more clearly that getting
correct results from that is not guaranteed.
There are already prohibitions in place on using SCROLL with
FOR UPDATE/SHARE, which is one way for a SELECT query to have
non-stable results. We could imagine prohibiting SCROLL when
the query contains volatile functions, but that would be
expensive to enforce. Moreover, it could break applications
that work just fine, if they have functions that are in fact
stable but the user neglected to mark them so. So settle for
documenting the hazard.
While this problem has existed in some guise for a long time,
it got a lot worse in v11, which introduced the possibility
of persisting plpgsql cursors (perhaps implicit ones) even
when they violate the rules for what can be marked WITH HOLD.
Hence, I've chosen to back-patch to v11 but not further.
Per bug #17050 from Алексей Булгаков.
Discussion: https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org
M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/ref/declare.sgml
M src/backend/commands/portalcmds.c
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql
Remove unnecessary declaration in win32_port.h
commit : b7684bd105657813e9366f8d664c22bcfb0e9f42
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 8 Jun 2021 13:40:10 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 8 Jun 2021 13:40:10 +0900
Mis-merge introduced by e2f21ff, where pgwin32_setenv() was listed but
not defined in win32env.c. This had no consequences as this routine
does not exist in this branch.
Only REL_12_STABLE and REL_13_STABLE got that wrong.
Backpatch-through: 12
M src/include/pg_config.h.win32
M src/include/port/win32_port.h
Stabilize contrib/seg regression test.
commit : 9ddd1c27ee27e6d06349e4dc84baf14333d23311
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Jun 2021 14:52:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Jun 2021 14:52:42 -0400
If autovacuum comes along just after we fill table test_seg with
some data, it will update the stats to the point where we prefer
a plain indexscan over a bitmap scan, breaking the expected
output (as well as the point of the test case). To fix, just
force a bitmap scan to be chosen here.
This has evidently been wrong since commit de1d042f5. It's not
clear why we just recently saw any buildfarm failures due to it;
but prairiedog has failed twice on this test in the past week.
Hence, backpatch to v11 where this test case came in.
M contrib/seg/expected/seg.out
M contrib/seg/sql/seg.sql
Fix incautious handling of possibly-miscoded strings in client code.
commit : fc896f45d6d859d9da52106cf42dc01dce88c224
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Jun 2021 14:15:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Jun 2021 14:15:25 -0400
An incorrectly-encoded multibyte character near the end of a string
could cause various processing loops to run past the string's
terminating NUL, with results ranging from no detectable issue to
a program crash, depending on what happens to be in the following
memory.
This isn't an issue in the server, because we take care to verify
the encoding of strings before doing any interesting processing
on them. However, that lack of care leaked into client-side code
which shouldn't assume that anyone has validated the encoding of
its input.
Although this is certainly a bug worth fixing, the PG security team
elected not to regard it as a security issue, primarily because
any untrusted text should be sanitized by PQescapeLiteral or
the like before being incorporated into a SQL or psql command.
(If an app fails to do so, the same technique can be used to
cause SQL injection, with probably much more dire consequences
than a mere client-program crash.) Those functions were already
made proof against this class of problem, cf CVE-2006-2313.
To fix, invent PQmblenBounded() which is like PQmblen() except it
won't return more than the number of bytes remaining in the string.
In HEAD we can make this a new libpq function, as PQmblen() is.
It seems imprudent to change libpq's API in stable branches though,
so in the back branches define PQmblenBounded as a macro in the files
that need it. (Note that just changing PQmblen's behavior would not
be a good idea; notably, it would completely break the escaping
functions' defense against this exact problem. So we just want a
version for those callers that don't have any better way of handling
this issue.)
Per private report from houjingyi. Back-patch to all supported branches.
M src/bin/psql/common.c
M src/bin/psql/psqlscanslash.l
M src/bin/psql/stringutils.c
M src/bin/psql/tab-complete.c
M src/bin/scripts/common.c
M src/fe_utils/print.c
M src/interfaces/libpq/fe-print.c
M src/interfaces/libpq/fe-protocol3.c
Remove leftover conflict marker
commit : 89f49cc3ad404c8bd6bdb7a4f30473948e581c34
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 5 Jun 2021 07:32:29 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 5 Jun 2021 07:32:29 +0200
M src/backend/access/transam/twophase.c
In PostgresNode.pm, don't pass SQL to psql on the command line
commit : 0c92ed165ec13672d615d81a5c5fb76580f92f13
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 3 Jun 2021 16:08:33 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 3 Jun 2021 16:08:33 -0400
The Msys shell mangles certain patterns in its command line, so avoid
handing arbitrary SQL to psql on the command line and instead use
IPC::Run's redirection facility for stdin. This pattern is already
mostly whats used, but query_poll_until() was not doing the right thing.
Problem discovered on the buildfarm when a new TAP test failed on msys.
M src/test/perl/PostgresNode.pm
Reduce risks of conflicts in internal queries of REFRESH MATVIEW CONCURRENTLY
commit : 4ceaa760bd8cf0e19f513a9b6fdf503037d8ff72
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 3 Jun 2021 15:28:41 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 3 Jun 2021 15:28:41 +0900
The internal SQL queries used by REFRESH MATERIALIZED VIEW CONCURRENTLY
include some aliases for its diff and temporary relations with
rather-generic names: diff, newdata, newdata2 and mv. Depending on the
queries used for the materialized view, using CONCURRENTLY could lead to
some internal failures if the query and those internal aliases conflict.
Those names have been chosen in 841c29c8. This commit switches instead
to a naming pattern which is less likely going to cause conflicts, based
on an idea from Thomas Munro, by appending _$ to those aliases. This is
not perfect as those new names could still conflict, but at least it has
the advantage to keep the code readable and simple while reducing the
likelihood of conflicts to be close to zero.
Reported-by: Mathis Rudolf
Author: Bharath Rupireddy
Reviewed-by: Bernd Helmle, Thomas Munro, Michael Paquier
Discussion: https://postgr.es/m/109c267a-10d2-3c53-b60e-720fcf44d9e8@credativ.de
Backpatch-through: 9.6
M src/backend/commands/matview.c
Ignore more environment variables in TAP tests
commit : ebd542bf4fd3dc8e9f2c8f145b57eccfd498a003
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 3 Jun 2021 11:51:47 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 3 Jun 2021 11:51:47 +0900
Various environment variables were not getting reset in the TAP tests,
which would cause failures depending on the tests or the environment
variables involved. For example, PGSSL{MAX,MIN}PROTOCOLVERSION could
cause failures in the SSL tests. Even worse, a junk value of
PGCLIENTENCODING makes a server startup fail. The list of variables
reset is adjusted in each stable branch depending on what is supported.
While on it, simplify a bit the code per a suggestion from Andrew
Dunstan, using a list of variables instead of doing single deletions.
Reviewed-by: Andrew Dunstan, Daniel Gustafsson
Discussion: https://postgr.es/m/YLbjjRpucIeZ78VQ@paquier.xyz
Backpatch-through: 9.6
M src/test/perl/TestLib.pm
Fix planner's row-mark code for inheritance from a foreign table.
commit : bdd096f1aec040574ff36a16946579b23a0e4879
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Jun 2021 14:38:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Jun 2021 14:38:14 -0400
Commit 428b260f8 broke planning of cases where row marks are needed
(SELECT FOR UPDATE, etc) and one of the query's tables is a foreign
table that has regular table(s) as inheritance children. We got the
reverse case right, but apparently were thinking that foreign tables
couldn't be inheritance parents. Not so; so we need to be able to
add a CTID junk column while adding a new child, not only a wholerow
junk column.
Back-patch to v12 where the faulty code came in.
Amit Langote
Discussion: https://postgr.es/m/CA+HiwqEmo3FV1LAQ4TVyS2h1WM=kMkZUmbNuZSCnfHvMcUcPeA@mail.gmail.com
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/optimizer/util/inherit.c
Reject SELECT ... GROUP BY GROUPING SETS (()) FOR UPDATE.
commit : 762fe98b1ba63101bbf1fe8fcd1e23532d2c4f41
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Jun 2021 11:12:56 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Jun 2021 11:12:56 -0400
This case should be disallowed, just as FOR UPDATE with a plain
GROUP BY is disallowed; FOR UPDATE only makes sense when each row
of the query result can be identified with a single table row.
However, we missed teaching CheckSelectLocking() to check
groupingSets as well as groupClause, so that it would allow
degenerate grouping sets. That resulted in a bad plan and
a null-pointer dereference in the executor.
Looking around for other instances of the same bug, the only one
I found was in examine_simple_variable(). That'd just lead to
silly estimates, but it should be fixed too.
Per private report from Yaoguang Chen.
Back-patch to all supported branches.
M src/backend/parser/analyze.c
M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/errors.out
M src/test/regress/sql/errors.sql
Add fallback implementation for setenv()
commit : 02037af3ff36d7a9023251c2fa4dc4efaa67bbf2
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 1 Jun 2021 09:27:31 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 1 Jun 2021 09:27:31 +0900
This fixes the code compilation on Windows with MSVC and Kerberos, as
a missing implementation of setenv() causes a compilation failure of the
GSSAPI code. This was only reproducible when building the code with
Kerberos, something that buildfarm animal hamerkop has fixed recently.
This issue only happens on 12 and 13, as this code has been introduced
in b0b39f7. HEAD is already able to compile properly thanks to
7ca37fb0, and this commit is a minimal cherry-pick of it.
Thanks to Tom Lane for the discussion.
Discussion: https://postgr.es/m/YLDtm5WGjPxm6ua4@paquier.xyz
Backpatch-through: 12
M configure
M configure.in
M src/include/pg_config.h.in
M src/include/pg_config.h.win32
M src/include/port.h
M src/include/port/win32_port.h
A src/port/setenv.c
M src/tools/msvc/Mkvcbuild.pm
Fix mis-planning of repeated application of a projection.
commit : 6f9e7f21fd32f45dfde962fc2bc28e01e193fb43
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 31 May 2021 12:03:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 31 May 2021 12:03:00 -0400
create_projection_plan contains a hidden assumption (here made
explicit by an Assert) that a projection-capable Path will yield a
projection-capable Plan. Unfortunately, that assumption is violated
only a few lines away, by create_projection_plan itself. This means
that two stacked ProjectionPaths can yield an outcome where we try to
jam the upper path's tlist into a non-projection-capable child node,
resulting in an invalid plan.
There isn't any good reason to have stacked ProjectionPaths; indeed the
whole concept is faulty, since the set of Vars/Aggs/etc needed by the
upper one wouldn't necessarily be available in the output of the lower
one, nor could the lower one create such values if they weren't
available from its input. Hence, we can fix this by adjusting
create_projection_path to strip any top-level ProjectionPath from the
subpath it's given. (This amounts to saying "oh, we changed our
minds about what we need to project here".)
The test case added here only fails in v13 and HEAD; before that, we
don't attempt to shove the Sort into the parallel part of the plan,
for reasons that aren't entirely clear to me. However, all the
directly-related code looks generally the same as far back as v11,
where the hazard was introduced (by d7c19e62a). So I've got no faith
that the same type of bug doesn't exist in v11 and v12, given the
right test case. Hence, back-patch the code changes, but not the
irrelevant test case, into those branches.
Per report from Bas Poot.
Discussion: https://postgr.es/m/534fca83789c4a378c7de379e9067d4f@politie.nl
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/util/pathnode.c
Raise a timeout to 180s, in test 010_logical_decoding_timelines.pl.
commit : 53b33e284c7b00eb5436060e26a096c798e4fa33
author : Noah Misch <noah@leadboat.com>
date : Mon, 31 May 2021 00:29:58 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 31 May 2021 00:29:58 -0700
Per buildfarm member hornet. Also, update Pod documentation showing the
lower value. Back-patch to v10, where the test first appeared.
M src/test/perl/PostgresNode.pm
M src/test/recovery/t/010_logical_decoding_timelines.pl
Fix race condition when sharing tuple descriptors.
commit : 82248f227b6d304e2da13655d8458a98682d2dac
author : Thomas Munro <tmunro@postgresql.org>
date : Sat, 29 May 2021 14:48:15 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Sat, 29 May 2021 14:48:15 +1200
Parallel query processes that called BlessTupleDesc() for identical
tuple descriptors at the same moment could crash. There was code to
handle that rare case, but it dereferenced a bogus DSA pointer. Repair.
Back-patch to 11, where commit cc5f8136 added support for sharing tuple
descriptors in parallel queries.
Reported-by: Eric Thinnes <e.thinnes@gmx.de>
Discussion: https://postgr.es/m/99aaa2eb-e194-bf07-c29a-1a76b4f2bcf9%40gmx.de
M src/backend/utils/cache/typcache.c
fix syntax error
commit : 40a05cf245b867f018a13e06ed3e9a2419a4090a
author : Andrew Dunstan <andrew@dunslane.net>
date : Fri, 28 May 2021 09:35:11 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Fri, 28 May 2021 09:35:11 -0400
M src/tools/msvc/Solution.pm
Report configured port in MSVC built pg_config
commit : ae3ef856938fed84a749215a738106af911cc23b
author : Andrew Dunstan <andrew@dunslane.net>
date : Fri, 28 May 2021 09:26:30 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Fri, 28 May 2021 09:26:30 -0400
This is a long standing omission, discovered when trying to write code
that relied on it.
Backpatch to all live branches.
M src/tools/msvc/Solution.pm
Fix MSVC scripts when building with GSSAPI/Kerberos
commit : a75268f1cbfbae0525eec7462b6aa36852894d6d
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 27 May 2021 20:11:24 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 27 May 2021 20:11:24 +0900
The deliverables of upstream Kerberos on Windows are installed with
paths that do not match our MSVC scripts. First, the include folder was
named "inc/" in our scripts, but the upstream MSIs use "include/".
Second, the build would fail with 64-bit environments as the libraries
are named differently.
This commit adjusts the MSVC scripts to be compatible with the latest
installations of upstream, and I have checked that the compilation was
able to work with the 32-bit and 64-bit installations.
Special thanks to Kondo Yuta for the help in investigating the situation
in hamerkop, which had an incorrect configuration for the GSS
compilation.
Reported-by: Brian Ye
Discussion: https://postgr.es/m/162128202219.27274.12616756784952017465@wrigleys.postgresql.org
Backpatch-through: 9.6
M src/tools/msvc/Solution.pm
doc: Fix description of some GUCs in docs and postgresql.conf.sample
commit : 99d6dd3b4d94d9d4b8036e733ca5fbd4f95b31fd
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 27 May 2021 14:58:13 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 27 May 2021 14:58:13 +0900
The following parameters have been imprecise, or incorrect, about their
description (PGC_POSTMASTER or PGC_SIGHUP):
- autovacuum_work_mem (docs, as of 9.6~)
- huge_page_size (docs, as of 14~)
- max_logical_replication_workers (docs, as of 10~)
- max_sync_workers_per_subscription (docs, as of 10~)
- min_dynamic_shared_memory (docs, as of 14~)
- recovery_init_sync_method (postgresql.conf.sample, as of 14~)
- remove_temp_files_after_crash (docs, as of 14~)
- restart_after_crash (docs, as of 9.6~)
- ssl_min_protocol_version (docs, as of 12~)
- ssl_max_protocol_version (docs, as of 12~)
This commit adjusts the description of all these parameters to be more
consistent with the practice used for the others.
Revewed-by: Justin Pryzby
Discussion: https://postgr.es/m/YK2ltuLpe+FbRXzA@paquier.xyz
Backpatch-through: 9.6
M doc/src/sgml/config.sgml
Disallow SSL renegotiation
commit : 3f8072be8a71b5bd3dc838a4ba03ccdaff2d975e
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 25 May 2021 10:11:17 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 25 May 2021 10:11:17 +0900
SSL renegotiation is already disabled as of 48d23c72, however this does
not prevent the server to comply with a client willing to use
renegotiation. In the last couple of years, renegotiation had its set
of security issues and flaws (like the recent CVE-2021-3449), and it
could be possible to crash the backend with a client attempting
renegotiation.
This commit takes one extra step by disabling renegotiation in the
backend in the same way as SSL compression (f9264d15) or tickets
(97d3a0b0). OpenSSL 1.1.0h has added an option named
SSL_OP_NO_RENEGOTIATION able to achieve that. In older versions
there is an option called SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS that
was undocumented, and could be set within the SSL object created when
the TLS connection opens, but I have decided not to use it, as it feels
trickier to rely on, and it is not official. Note that this option is
not usable in OpenSSL < 1.1.0h as the internal contents of the *SSL
object are hidden to applications.
SSL renegotiation concerns protocols up to TLSv1.2.
Per original report from Robert Haas, with a patch based on a suggestion
by Andres Freund.
Author: Michael Paquier
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/YKZBXx7RhU74FlTE@paquier.xyz
Backpatch-through: 9.6
M src/backend/libpq/be-secure-openssl.c
Disallow whole-row variables in GENERATED expressions.
commit : 61feb8670824c8dfb66094f2a87df2395be0665c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 May 2021 15:12:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 May 2021 15:12:08 -0400
This was previously allowed, but I think that was just an oversight.
It's a clear violation of the rule that a generated column cannot
depend on itself or other generated columns. Moreover, because the
code was relying on the assumption that no such cross-references
exist, it was pretty easy to crash ALTER TABLE and perhaps other
places. Even if you managed not to crash, you got quite unstable,
implementation-dependent results.
Per report from Vitaly Ustinov.
Back-patch to v12 where GENERATED came in.
Discussion: https://postgr.es/m/CAM_DEiWR2DPT6U4xb-Ehigozzd3n3G37ZB1+867zbsEVtYoJww@mail.gmail.com
M src/backend/catalog/heap.c
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql
Fix usage of "tableoid" in GENERATED expressions.
commit : dfe51ffbe78a16368073c2838c04e603d3d76915
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 May 2021 15:02:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 May 2021 15:02:07 -0400
We consider this supported (though I've got my doubts that it's a
good idea, because tableoid is not immutable). However, several
code paths failed to fill the field in soon enough, causing such
a GENERATED expression to see zero or the wrong value. This
occurred when ALTER TABLE adds a new GENERATED column to a table
with existing rows, and during regular INSERT or UPDATE on a
foreign table with GENERATED columns.
Noted during investigation of a report from Vitaly Ustinov.
Back-patch to v12 where GENERATED came in.
Discussion: https://postgr.es/m/CAM_DEiWR2DPT6U4xb-Ehigozzd3n3G37ZB1+867zbsEVtYoJww@mail.gmail.com
M src/backend/commands/tablecmds.c
M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql
Restore the portal-level snapshot after procedure COMMIT/ROLLBACK.
commit : 41c6a5bec25e720d98bd60d77dd5c2939189ed3c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 May 2021 14:03:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 May 2021 14:03:53 -0400
COMMIT/ROLLBACK necessarily destroys all snapshots within the session.
The original implementation of intra-procedure transactions just
cavalierly did that, ignoring the fact that this left us executing in
a rather different environment than normal. In particular, it turns
out that handling of toasted datums depends rather critically on there
being an outer ActiveSnapshot: otherwise, when SPI or the core
executor pop whatever snapshot they used and return, it's unsafe to
dereference any toasted datums that may appear in the query result.
It's possible to demonstrate "no known snapshots" and "missing chunk
number N for toast value" errors as a result of this oversight.
Historically this outer snapshot has been held by the Portal code,
and that seems like a good plan to preserve. So add infrastructure
to pquery.c to allow re-establishing the Portal-owned snapshot if it's
not there anymore, and add enough bookkeeping support that we can tell
whether it is or not.
We can't, however, just re-establish the Portal snapshot as part of
COMMIT/ROLLBACK. As in normal transaction start, acquiring the first
snapshot should wait until after SET and LOCK commands. Hence, teach
spi.c about doing this at the right time. (Note that this patch
doesn't fix the problem for any PLs that try to run intra-procedure
transactions without using SPI to execute SQL commands.)
This makes SPI's no_snapshots parameter rather a misnomer, so in HEAD,
rename that to allow_nonatomic.
replication/logical/worker.c also needs some fixes, because it wasn't
careful to hold a snapshot open around AFTER trigger execution.
That code doesn't use a Portal, which I suspect someday we're gonna
have to fix. But for now, just rearrange the order of operations.
This includes back-patching the recent addition of finish_estate()
to centralize the cleanup logic there.
This also back-patches commit 2ecfeda3e into v13, to improve the
test coverage for worker.c (it was that test that exposed that
worker.c's snapshot management is wrong).
Per bug #15990 from Andreas Wicht. Back-patch to v11 where
intra-procedure COMMIT was added.
Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org
M src/backend/commands/functioncmds.c
M src/backend/executor/spi.c
M src/backend/replication/logical/worker.c
M src/backend/tcop/pquery.c
M src/backend/utils/mmgr/portalmem.c
M src/include/executor/spi_priv.h
M src/include/tcop/pquery.h
M src/include/utils/portal.h
M src/pl/plpgsql/src/pl_exec.c
M src/test/isolation/expected/plpgsql-toast.out
M src/test/isolation/specs/plpgsql-toast.spec
Fix deadlock for multiple replicating truncates of the same table.
commit : 18c6242b7c6da78341b6745bc9b0bcbca20d556b
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 21 May 2021 08:17:25 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 21 May 2021 08:17:25 +0530
While applying the truncate change, the logical apply worker acquires
RowExclusiveLock on the relation being truncated. This allowed truncate on
the relation at a time by two apply workers which lead to a deadlock. The
reason was that one of the workers after updating the pg_class tuple tries
to acquire SHARE lock on the relation and started to wait for the second
worker which has acquired RowExclusiveLock on the relation. And when the
second worker tries to update the pg_class tuple, it starts to wait for
the first worker which leads to a deadlock. Fix it by acquiring
AccessExclusiveLock on the relation before applying the truncate change as
we do for normal truncate operation.
Author: Peter Smith, test case by Haiying Tang
Reviewed-by: Dilip Kumar, Amit Kapila
Backpatch-through: 11
Discussion: https://postgr.es/m/CAHut+PsNm43p0jM+idTvWwiGZPcP0hGrHMPK9TOAkc+a4UpUqw@mail.gmail.com
M src/backend/replication/logical/worker.c
M src/test/subscription/t/010_truncate.pl
Avoid detoasting failure after COMMIT inside a plpgsql FOR loop.
commit : 8d341d6cb6c9b3f2ae29837f43857349c6684ab2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 May 2021 18:32:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 May 2021 18:32:37 -0400
exec_for_query() normally tries to prefetch a few rows at a time
from the query being iterated over, so as to reduce executor
entry/exit overhead. Unfortunately this is unsafe if we have
COMMIT or ROLLBACK within the loop, because there might be
TOAST references in the data that we prefetched but haven't
yet examined. Immediately after the COMMIT/ROLLBACK, we have
no snapshots in the session, meaning that VACUUM is at liberty
to remove recently-deleted TOAST rows.
This was originally reported as a case triggering the "no known
snapshots" error in init_toast_snapshot(), but even if you miss
hitting that, you can get "missing toast chunk", as illustrated
by the added isolation test case.
To fix, just disable prefetching in non-atomic contexts. Maybe
there will be performance complaints prompting us to work harder
later, but it's not clear at the moment that this really costs
much, and I doubt we'd want to back-patch any complicated fix.
In passing, adjust that error message in init_toast_snapshot()
to be a little clearer about the likely cause of the problem.
Patch by me, based on earlier investigation by Konstantin Knizhnik.
Per bug #15990 from Andreas Wicht. Back-patch to v11 where
intra-procedure COMMIT was added.
Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org
M src/backend/access/heap/tuptoaster.c
M src/pl/plpgsql/src/pl_exec.c
M src/test/isolation/expected/plpgsql-toast.out
M src/test/isolation/specs/plpgsql-toast.spec
Clean up cpluspluscheck violation.
commit : 0b2686032bac25f4950551d18de210e1041258eb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 May 2021 13:03:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 May 2021 13:03:09 -0400
"typename" is a C++ keyword, so pg_upgrade.h fails to compile in C++.
Fortunately, there seems no likely reason for somebody to need to
do that. Nonetheless, it's project policy that all .h files should
pass cpluspluscheck, so rename the argument to fix that.
Oversight in 57c081de0; back-patch as that was. (The policy requiring
pg_upgrade.h to pass cpluspluscheck only goes back to v12, but it
seems best to keep this code looking the same in all branches.)
M src/bin/pg_upgrade/pg_upgrade.h
M src/bin/pg_upgrade/version.c
Fix typo and outdated information in README.barrier
commit : 898c62951e8090923155fe6ba20935517b15c188
author : David Rowley <drowley@postgresql.org>
date : Tue, 18 May 2021 09:56:31 +1200
committer: David Rowley <drowley@postgresql.org>
date : Tue, 18 May 2021 09:56:31 +1200
README.barrier didn't seem to get the memo when atomics were added. Fix
that.
Author: Tatsuo Ishii, David Rowley
Discussion: https://postgr.es/m/20210516.211133.2159010194908437625.t-ishii%40sraoss.co.jp
Backpatch-through: 9.6, oldest supported release
M src/backend/storage/lmgr/README.barrier
Be more careful about barriers when releasing BackgroundWorkerSlots.
commit : 6bcb51968c2719063b31c95b339a071a392c4beb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 May 2021 12:21:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 May 2021 12:21:06 -0400
ForgetBackgroundWorker lacked any memory barrier at all, while
BackgroundWorkerStateChange had one but unaccountably did
additional manipulation of the slot after the barrier. AFAICS,
the rule must be that the barrier is immediately before setting
or clearing slot->in_use.
It looks like back in 9.6 when ForgetBackgroundWorker was first
written, there might have been some case for not needing a
barrier there, but I'm not very convinced of that --- the fact
that the load of bgw_notify_pid is in the caller doesn't seem
to guarantee no memory ordering problem. So patch 9.6 too.
It's likely that this doesn't fix any observable bug on Intel
hardware, but machines with weaker memory ordering rules could
have problems here.
Discussion: https://postgr.es/m/4046084.1620244003@sss.pgh.pa.us
M src/backend/postmaster/bgworker.c
Doc: correct erroneous entry in this week's minor release notes.
commit : 0a536004b7d943416cb62703d2081006c1f5616e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 May 2021 17:36:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 May 2021 17:36:20 -0400
The patch to disallow a NULL specification in combination with
GENERATED ... AS IDENTITY applied to both ALWAYS and BY DEFAULT
variants of that clause, not only the former.
Noted by Shay Rojansky.
Discussion: https://postgr.es/m/CADT4RqAwD3A=RvGiQU9AiTK-6VeuXcycwPHmJPv_OBCJFYOEww@mail.gmail.com
M doc/src/sgml/release-12.sgml
Prevent infinite insertion loops in spgdoinsert().
commit : 4e046281fb58b9986bc6de63ae3c6a8bb38342e5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 May 2021 15:07:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 May 2021 15:07:34 -0400
Formerly we just relied on operator classes that assert longValuesOK
to eventually shorten the leaf value enough to fit on an index page.
That fails since the introduction of INCLUDE-column support (commit
09c1c6ab4), because the INCLUDE columns might alone take up more
than a page, meaning no amount of leaf-datum compaction will get
the job done. At least with spgtextproc.c, that leads to an infinite
loop, since spgtextproc.c won't throw an error for not being able
to shorten the leaf datum anymore.
To fix without breaking cases that would otherwise work, add logic
to spgdoinsert() to verify that the leaf tuple size is decreasing
after each "choose" step. Some opclasses might not decrease the
size on every single cycle, and in any case, alignment roundoff
of the tuple size could obscure small gains. Therefore, allow
up to 10 cycles without additional savings before throwing an
error. (Perhaps this number will need adjustment, but it seems
quite generous right now.)
As long as we've developed this logic, let's back-patch it.
The back branches don't have INCLUDE columns to worry about, but
this seems like a good defense against possible bugs in operator
classes. We already know that an infinite loop here is pretty
unpleasant, so having a defense seems to outweigh the risk of
breaking things. (Note that spgtextproc.c is actually the only
known opclass with longValuesOK support, so that this is all moot
for known non-core opclasses anyway.)
Per report from Dilip Kumar.
Discussion: https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com
M doc/src/sgml/spgist.sgml
M src/backend/access/spgist/spgdoinsert.c
Fix query-cancel handling in spgdoinsert().
commit : 004288d3c0ac4f516ae728b200127e0783d3e375
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 May 2021 13:26:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 May 2021 13:26:55 -0400
Knowing that a buggy opclass could cause an infinite insertion loop,
spgdoinsert() intended to allow its loop to be interrupted by query
cancel. However, that never actually worked, because in iterations
after the first, we'd be holding buffer lock(s) which would cause
InterruptHoldoffCount to be positive, preventing servicing of the
interrupt.
To fix, check if an interrupt is pending, and if so fall out of
the insertion loop and service the interrupt after we've released
the buffers. If it was indeed a query cancel, that's the end of
the matter. If it was a non-canceling interrupt reason, make use
of the existing provision to retry the whole insertion. (This isn't
as wasteful as it might seem, since any upper-level index tuples we
already created should be usable in the next attempt.)
While there's no known instance of such a bug in existing release
branches, it still seems like a good idea to back-patch this to
all supported branches, since the behavior is fairly nasty if a
loop does happen --- not only is it uncancelable, but it will
quickly consume memory to the point of an OOM failure. In any
case, this code is certainly not working as intended.
Per report from Dilip Kumar.
Discussion: https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com
M src/backend/access/spgist/spgdoinsert.c
Refactor CHECK_FOR_INTERRUPTS() to add flexibility.
commit : 4c646b17985cdca9506428ebe2b13ebc5109c35a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 May 2021 12:54:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 May 2021 12:54:26 -0400
Split up CHECK_FOR_INTERRUPTS() to provide an additional macro
INTERRUPTS_PENDING_CONDITION(), which just tests whether an
interrupt is pending without attempting to service it. This is
useful in situations where the caller knows that interrupts are
blocked, and would like to find out if it's worth the trouble
to unblock them.
Also add INTERRUPTS_CAN_BE_PROCESSED(), which indicates whether
CHECK_FOR_INTERRUPTS() can be relied on to clear the pending interrupt.
This commit doesn't actually add any uses of the new macros,
but a follow-on bug fix will do so. Back-patch to all supported
branches to provide infrastructure for that fix.
Alvaro Herrera and Tom Lane
Discussion: https://postgr.es/m/20210513155351.GA7848@alvherre.pgsql
M src/backend/tcop/postgres.c
M src/include/miscadmin.h
Improve documentation example for jsonpath like_regex operator
commit : f0d20e5973a26207c0e8efbb09e0b1cf7c27cc64
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 13 May 2021 16:10:21 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 13 May 2021 16:10:21 +0300
Make sample like_regex match string values of the root object instead of the
whole document. The corrected example seems to represent a more relevant
use case.
Backpatch to 12, when jsonpath was introduced.
Discussion: https://postgr.es/m/13440f8b-4c1f-5875-c8e3-f3f65606af2f%40xs4all.nl
Author: Erik Rijkers
Reviewed-by: Michael Paquier, Alexander Korotkov
Backpatch-through: 12
M doc/src/sgml/func.sgml
Rename the logical replication global "wrconn"
commit : 6e9723cde5c672bb55ed803fc42720d0a46ce03c
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 12 May 2021 19:13:54 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 12 May 2021 19:13:54 -0400
The worker.c global wrconn is only meant to be used by logical apply/
tablesync workers, but there are other variables with the same name. To
reduce future confusion rename the global from "wrconn" to
"LogRepWorkerWalRcvConn".
While this is just cosmetic, it seems better to backpatch it all the way
back to 10 where this code appeared, to avoid future backpatching
issues.
Author: Peter Smith <smithpb2250@gmail.com>
Discussion: https://postgr.es/m/CAHut+Pu7Jv9L2BOEx_Z0UtJxfDevQSAUW2mJqWU+CtmDrEZVAg@mail.gmail.com
M src/backend/replication/logical/launcher.c
M src/backend/replication/logical/tablesync.c
M src/backend/replication/logical/worker.c
M src/include/replication/worker_internal.h