Stamp 12.7.
commit : 4bf0bce161097869be5a56706b31388ba15e0113
author : Tom Lane <[email protected]>
date : Mon, 10 May 2021 16:43:52 -0400
committer: Tom Lane <[email protected]>
date : Mon, 10 May 2021 16:43:52 -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 : a9c718bd2d35586da8ebdefa0b72fe7e0d1a725b
author : Tom Lane <[email protected]>
date : Mon, 10 May 2021 13:10:29 -0400
committer: Tom Lane <[email protected]>
date : Mon, 10 May 2021 13:10:29 -0400
Security: CVE-2021-32027, CVE-2021-32028, CVE-2021-32029
M doc/src/sgml/release-12.sgml
Fix mishandling of resjunk columns in ON CONFLICT ... UPDATE tlists.
commit : a5fa3e0671474411ad81600a8f2b4800a4464afc
author : Tom Lane <[email protected]>
date : Mon, 10 May 2021 11:02:29 -0400
committer: Tom Lane <[email protected]>
date : Mon, 10 May 2021 11:02:29 -0400
It's unusual to have any resjunk columns in an ON CONFLICT ... UPDATE
list, but it can happen when MULTIEXPR_SUBLINK SubPlans are present.
If it happens, the ON CONFLICT UPDATE code path would end up storing
tuples that include the values of the extra resjunk columns. That's
fairly harmless in the short run, but if new columns are added to
the table then the values would become accessible, possibly leading
to malfunctions if they don't match the datatypes of the new columns.
This had escaped notice through a confluence of missing sanity checks,
including
* There's no cross-check that a tuple presented to heap_insert or
heap_update matches the table rowtype. While it's difficult to
check that fully at reasonable cost, we can easily add assertions
that there aren't too many columns.
* The output-column-assignment cases in execExprInterp.c lacked
any sanity checks on the output column numbers, which seems like
an oversight considering there are plenty of assertion checks on
input column numbers. Add assertions there too.
* We failed to apply nodeModifyTable's ExecCheckPlanOutput() to
the ON CONFLICT UPDATE tlist. That wouldn't have caught this
specific error, since that function is chartered to ignore resjunk
columns; but it sure seems like a bad omission now that we've seen
this bug.
In HEAD, the right way to fix this is to make the processing of
ON CONFLICT UPDATE tlists work the same as regular UPDATE tlists
now do, that is don't add "SET x = x" entries, and use
ExecBuildUpdateProjection to evaluate the tlist and combine it with
old values of the not-set columns. This adds a little complication
to ExecBuildUpdateProjection, but allows removal of a comparable
amount of now-dead code from the planner.
In the back branches, the most expedient solution seems to be to
(a) use an output slot for the ON CONFLICT UPDATE projection that
actually matches the target table, and then (b) invent a variant of
ExecBuildProjectionInfo that can be told to not store values resulting
from resjunk columns, so it doesn't try to store into nonexistent
columns of the output slot. (We can't simply ignore the resjunk columns
altogether; they have to be evaluated for MULTIEXPR_SUBLINK to work.)
This works back to v10. In 9.6, projections work much differently and
we can't cheaply give them such an option. The 9.6 version of this
patch works by inserting a JunkFilter when it's necessary to get rid
of resjunk columns.
In addition, v11 and up have the reverse problem when trying to
perform ON CONFLICT UPDATE on a partitioned table. Through a
further oversight, adjust_partition_tlist() discarded resjunk columns
when re-ordering the ON CONFLICT UPDATE tlist to match a partition.
This accidentally prevented the storing-bogus-tuples problem, but
at the cost that MULTIEXPR_SUBLINK cases didn't work, typically
crashing if more than one row has to be updated. Fix by preserving
resjunk columns in that routine. (I failed to resist the temptation
to add more assertions there too, and to do some minor code
beautification.)
Per report from Andres Freund. Back-patch to all supported branches.
Security: CVE-2021-32028
M src/backend/access/heap/heapam.c
M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/backend/executor/execPartition.c
M src/backend/executor/nodeModifyTable.c
M src/include/executor/executor.h
M src/test/regress/expected/update.out
M src/test/regress/sql/update.sql
Prevent integer overflows in array subscripting calculations.
commit : 3b0f6a7ae5d812d9a70fc854d2e54d3657467e25
author : Tom Lane <[email protected]>
date : Mon, 10 May 2021 10:44:38 -0400
committer: Tom Lane <[email protected]>
date : Mon, 10 May 2021 10:44:38 -0400
While we were (mostly) careful about ensuring that the dimensions of
arrays aren't large enough to cause integer overflow, the lower bound
values were generally not checked. This allows situations where
lower_bound + dimension overflows an integer. It seems that that's
harmless so far as array reading is concerned, except that array
elements with subscripts notionally exceeding INT_MAX are inaccessible.
However, it confuses various array-assignment logic, resulting in a
potential for memory stomps.
Fix by adding checks that array lower bounds aren't large enough to
cause lower_bound + dimension to overflow. (Note: this results in
disallowing cases where the last subscript position would be exactly
INT_MAX. In principle we could probably allow that, but there's a lot
of code that computes lower_bound + dimension and would need adjustment.
It seems doubtful that it's worth the trouble/risk to allow it.)
Somewhat independently of that, array_set_element() was careless
about possible overflow when checking the subscript of a fixed-length
array, creating a different route to memory stomps. Fix that too.
Security: CVE-2021-32027
M src/backend/executor/execExprInterp.c
M src/backend/utils/adt/array_userfuncs.c
M src/backend/utils/adt/arrayfuncs.c
M src/backend/utils/adt/arrayutils.c
M src/include/utils/array.h
Translation updates
commit : c5edbfeb172722eb5a0ef50aa8c449545de9b321
author : Peter Eisentraut <[email protected]>
date : Mon, 10 May 2021 14:30:04 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 10 May 2021 14:30:04 +0200
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 7221ef1e0bfee1318f195b8faca683c0ffbee895
M src/backend/po/de.po
M src/backend/po/fr.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/fr.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/fr.po
Release notes for 13.3, 12.7, 11.12, 10.17, 9.6.22.
commit : dc7816eb845f6686cac2b42303cb82de1c30f265
author : Tom Lane <[email protected]>
date : Sun, 9 May 2021 13:31:40 -0400
committer: Tom Lane <[email protected]>
date : Sun, 9 May 2021 13:31:40 -0400
M doc/src/sgml/release-12.sgml
AlterSubscription_refresh: avoid stomping on global variable
commit : cfebc7080c990d60183cc486861d07db9dd8808b
author : Alvaro Herrera <[email protected]>
date : Fri, 7 May 2021 11:46:37 -0400
committer: Alvaro Herrera <[email protected]>
date : Fri, 7 May 2021 11:46:37 -0400
This patch replaces use of the global "wrconn" variable in
AlterSubscription_refresh with a local variable of the same name, making
it consistent with other functions in subscriptioncmds.c (e.g.
DropSubscription).
The global wrconn is only meant to be used for logical apply/tablesync worker.
Abusing it this way is known to cause trouble if an apply worker
manages to do a subscription refresh, such as reported by Jeremy Finzel
and diagnosed by Andres Freund back in November 2020, at
https://www.postgresql.org/message-id/[email protected]
Backpatch to 10. In branch master, also move the connection establishment
to occur outside the PG_TRY block; this way we can remove a test for NULL in
PG_FINALLY, and it also makes the code more consistent with similar code in
the same file.
Author: Peter Smith <[email protected]>
Reviewed-by: Bharath Rupireddy <[email protected]>
Reviewed-by: Japin Li <[email protected]>
Discussion: https://postgr.es/m/CAHut+Pu7Jv9L2BOEx_Z0UtJxfDevQSAUW2mJqWU+CtmDrEZVAg@mail.gmail.com
M src/backend/commands/subscriptioncmds.c
Document lock level used by ALTER TABLE VALIDATE CONSTRAINT
commit : b075e08d869b3f73ad1221098c331ddb01005a89
author : Alvaro Herrera <[email protected]>
date : Thu, 6 May 2021 17:17:56 -0400
committer: Alvaro Herrera <[email protected]>
date : Thu, 6 May 2021 17:17:56 -0400
Backpatch all the way back to 9.6.
Author: Simon Riggs <[email protected]>
Discussion: https://postgr.es/m/CANbhV-EwxvdhHuOLdfG2ciYrHOHXV=mm6=fD5aMhqcH09Li3Tg@mail.gmail.com
M doc/src/sgml/ref/alter_table.sgml
Have ALTER CONSTRAINT recurse on partitioned tables
commit : abce26c9eb95698c5bd07ae21ce4df5d45e3c02b
author : Alvaro Herrera <[email protected]>
date : Wed, 5 May 2021 12:14:21 -0400
committer: Alvaro Herrera <[email protected]>
date : Wed, 5 May 2021 12:14:21 -0400
When ALTER TABLE .. ALTER CONSTRAINT changes deferrability properties
changed in a partitioned table, we failed to propagate those changes
correctly to partitions and to triggers. Repair by adding a recursion
mechanism to affect all derived constraints and all derived triggers.
(In particular, recurse to partitions even if their respective parents
are already in the desired state: it is possible for the partitions to
have been altered individually.) Because foreign keys involve tables in
two sides, we cannot use the standard ALTER TABLE recursion mechanism,
so we invent our own by following pg_constraint.conparentid down.
When ALTER TABLE .. ALTER CONSTRAINT is invoked on the derived
pg_constraint object that's automaticaly created in a partition as a
result of a constraint added to its parent, raise an error instead of
pretending to work and then failing to modify all the affected triggers.
Before this commit such a command would be allowed but failed to affect
all triggers, so it would silently misbehave. (Restoring dumps of
existing databases is not affected, because pg_dump does not produce
anything for such a derived constraint anyway.)
Add some tests for the case.
Backpatch to 11, where foreign key support was added to partitioned
tables by commit 3de241dba86f. (A related change is commit f56f8f8da6af
in pg12 which added support for FKs *referencing* partitioned tables;
this is what forces us to use an ad-hoc recursion mechanism for this.)
Diagnosed by Tom Lane from bug report from Ron L Johnson. As of this
writing, no reviews were offered.
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Fix OID passed to object-alter hook during ALTER CONSTRAINT
commit : 72fabd4bfb5a8189591933cf244eabcaf83d4b8b
author : Alvaro Herrera <[email protected]>
date : Tue, 4 May 2021 10:09:11 -0400
committer: Alvaro Herrera <[email protected]>
date : Tue, 4 May 2021 10:09:11 -0400
The OID of the constraint is used instead of the OID of the trigger --
an easy mistake to make. Apparently the object-alter hooks are not very
well tested :-(
Backpatch to 12, where this typo was introduced by 578b229718e8
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
pg_dump: Fix dump of generated columns in partitions
commit : bdaa0d2d726911e31b19ed3a02ecb33dfc6d3673
author : Peter Eisentraut <[email protected]>
date : Tue, 4 May 2021 14:03:54 +0200
committer: Peter Eisentraut <[email protected]>
date : Tue, 4 May 2021 14:03:54 +0200
The previous fix for dumping of inherited generated columns
(0bf83648a52df96f7c8677edbbdf141bfa0cf32b) must not be applied to
partitions, since, unlike normal inherited tables, they are always
dumped separately and reattached.
Reported-by: Santosh Udupi <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/CACLRvHZ4a-%2BSM_159%2BtcrHdEqxFrG%3DW4gwTRnwf7Oj0UNj5R2A%40mail.gmail.com
M src/bin/pg_dump/common.c
Fix ALTER TABLE / INHERIT with generated columns
commit : 13ff139a238480cd3221c51c269d5ccdd429594f
author : Peter Eisentraut <[email protected]>
date : Tue, 4 May 2021 11:45:37 +0200
committer: Peter Eisentraut <[email protected]>
date : Tue, 4 May 2021 11:45:37 +0200
When running ALTER TABLE t2 INHERIT t1, we must check that columns in
t2 that correspond to a generated column in t1 are also generated and
have the same generation expression. Otherwise, this would allow
creating setups that a normal CREATE TABLE sequence would not allow.
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/commands/tablecmds.c
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql
Doc: add an example of a self-referential foreign key to ddl.sgml.
commit : bd9e46a1a4acafa170e9dbf35299518a216ffa41
author : Tom Lane <[email protected]>
date : Fri, 30 Apr 2021 15:37:56 -0400
committer: Tom Lane <[email protected]>
date : Fri, 30 Apr 2021 15:37:56 -0400
While we've always allowed such cases, the documentation didn't
say you could do it.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ddl.sgml
Doc: update libpq's documentation for PQfn().
commit : 8e9b7c63877094bee343283d00b4e29bd9bb4ffa
author : Tom Lane <[email protected]>
date : Fri, 30 Apr 2021 15:10:06 -0400
committer: Tom Lane <[email protected]>
date : Fri, 30 Apr 2021 15:10:06 -0400
Mention specifically that you can't call aggregates, window functions,
or procedures this way (the inability to call SRFs was already
mentioned).
Also, the claim that PQfn doesn't support NULL arguments or results
has been a lie since we invented protocol 3.0. Not sure why this
text was never updated for that, but do it now.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/libpq.sgml
Disallow calling anything but plain functions via the fastpath API.
commit : 89768ee696bfe1dd77dcd3f84cb10817aa379874
author : Tom Lane <[email protected]>
date : Fri, 30 Apr 2021 14:10:26 -0400
committer: Tom Lane <[email protected]>
date : Fri, 30 Apr 2021 14:10:26 -0400
Reject aggregates, window functions, and procedures. Aggregates
failed anyway, though with a somewhat obscure error message.
Window functions would hit an Assert or null-pointer dereference.
Procedures seemed to work as long as you didn't try to do
transaction control, but (a) transaction control is sort of the
point of a procedure, and (b) it's not entirely clear that no
bugs lurk in that path. Given the lack of testing of this area,
it seems safest to be conservative in what we support.
Also reject proretset functions, as the fastpath protocol can't
support returning a set.
Also remove an easily-triggered assertion that the given OID
isn't 0; the subsequent lookups can handle that case themselves.
Per report from Theodor-Arsenij Larionov-Trichkin.
Back-patch to all supported branches. (The procedure angle
only applies in v11+, of course.)
Discussion: https://postgr.es/m/[email protected]
M src/backend/tcop/fastpath.c
Fix some more omissions in pg_upgrade's tests for non-upgradable types.
commit : ba86371b9ca048eeffc5f26530b78f64f2884ed5
author : Tom Lane <[email protected]>
date : Thu, 29 Apr 2021 15:24:37 -0400
committer: Tom Lane <[email protected]>
date : Thu, 29 Apr 2021 15:24:37 -0400
Commits 29aeda6e4 et al closed up some oversights involving not checking
for non-upgradable types within container types, such as arrays and
ranges. However, I only looked at version.c, failing to notice that
there were substantially-equivalent tests in check.c. (The division
of responsibility between those files is less than clear...)
In addition, because genbki.pl does not guarantee that auto-generated
rowtype OIDs will hold still across versions, we need to consider that
the composite type associated with a system catalog or view is
non-upgradable. It seems unlikely that someone would have a user
column declared that way, but if they did, trying to read it in another
PG version would likely draw "no such pg_type OID" failures, thanks
to the type OID embedded in composite Datums.
To support the composite and reg*-type cases, extend the recursive
query that does the search to allow any base query that returns
a column of pg_type OIDs, rather than limiting it to exactly one
starting type.
As before, back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_upgrade/check.c
M src/bin/pg_upgrade/pg_upgrade.h
M src/bin/pg_upgrade/version.c
Improve documentation for default_tablespace on partitioned tables
commit : adbcd3e6634aa37c86bd8d5463dab552c22510f9
author : Alvaro Herrera <[email protected]>
date : Thu, 29 Apr 2021 11:31:24 -0400
committer: Alvaro Herrera <[email protected]>
date : Thu, 29 Apr 2021 11:31:24 -0400
Backpatch to 12, where 87259588d0ab introduced the current behavior.
Per note from Justin Pryzby.
Co-authored-by: Justin Pryzby <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/config.sgml
Doc: fix discussion of how to get real Julian Dates.
commit : 824df1cccb74f5f634439ecf6c9828fea6ecc3ef
author : Tom Lane <[email protected]>
date : Wed, 28 Apr 2021 10:03:28 -0400
committer: Tom Lane <[email protected]>
date : Wed, 28 Apr 2021 10:03:28 -0400
Somehow I'd convinced myself that rotating to UTC-12 was the way
to do this, but upon further review, it's definitely UTC+12.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/datetime.sgml
Fix use-after-release issue with pg_identify_object_as_address()
commit : 85a3e0be1e94b4e0e94d1480f43fe47ce7f68b62
author : Michael Paquier <[email protected]>
date : Wed, 28 Apr 2021 11:58:46 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 28 Apr 2021 11:58:46 +0900
Spotted by buildfarm member prion, with -DRELCACHE_FORCE_RELEASE.
Introduced in f7aab36.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M src/backend/catalog/objectaddress.c
Fix pg_identify_object_as_address() with event triggers
commit : 7e76cb1d82bcc2d39a3d70930822c247d6a034d8
author : Michael Paquier <[email protected]>
date : Wed, 28 Apr 2021 11:18:20 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 28 Apr 2021 11:18:20 +0900
Attempting to use this function with event triggers failed, as, since
its introduction in a676201, this code has never associated an object
name with event triggers. This addresses the failure by adding the
event trigger name to the set defining its object address.
Note that regression tests are added within event_trigger and not
object_address to avoid issues with concurrent connections in parallel
schedules.
Author: Joel Jacobson
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M src/backend/catalog/objectaddress.c
M src/test/regress/expected/event_trigger.out
M src/test/regress/sql/event_trigger.sql
Doc: document EXTRACT(JULIAN ...), improve Julian Date explanation.
commit : b230618ce8759147e838c3a08709685cddca2468
author : Tom Lane <[email protected]>
date : Mon, 26 Apr 2021 11:50:35 -0400
committer: Tom Lane <[email protected]>
date : Mon, 26 Apr 2021 11:50:35 -0400
For some reason, the "julian" option for extract()/date_part() has
never gotten listed in the manual. Also, while Appendix B mentioned
in passing that we don't conform to the usual astronomical definition
that a Julian date starts at noon UTC, it was kind of vague about what
we do instead. Clarify that, and add an example showing how to get
the astronomical definition if you want it.
It's been like this for ages, so back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/datetime.sgml
M doc/src/sgml/func.sgml
doc: Fix obsolete description about pg_basebackup.
commit : 0ecc88076ed2eb52b36261ee82c5c5fc93c10b6c
author : Fujii Masao <[email protected]>
date : Fri, 23 Apr 2021 15:45:46 +0900
committer: Fujii Masao <[email protected]>
date : Fri, 23 Apr 2021 15:45:46 +0900
Previously it was documented that if using "-X none" option there was
no guarantee that all required WAL files were archived at the end of
pg_basebackup when taking a backup from the standby. But this limitation
was removed by commit 52f8a59dd9. Now, even when taking a backup
from the standby, pg_basebackup can wait for all required WAL files
to be archived. Therefore this commit removes such obsolete
description from the docs.
Also this commit adds new description about the limitation when
taking a backup from the standby, into the docs. The limitation is that
pg_basebackup cannot force the standbfy to switch to a new WAL file
at the end of backup, which may cause pg_basebackup to wait a long
time for the last required WAL file to be switched and archived,
especially when write activity on the primary is low.
Back-patch to v10 where the issue was introduced.
Reported-by: Kyotaro Horiguchi
Author: Kyotaro Horiguchi, Fujii Masao
Reviewed-by: Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/pg_basebackup.sgml
Don't crash on reference to an un-available system column.
commit : 05ce4bf8b1d45cc55762fab627ea91d1ffbbdc03
author : Tom Lane <[email protected]>
date : Thu, 22 Apr 2021 17:30:42 -0400
committer: Tom Lane <[email protected]>
date : Thu, 22 Apr 2021 17:30:42 -0400
Adopt a more consistent policy about what slot-type-specific
getsysattr functions should do when system attributes are not
available. To wit, they should all throw the same user-oriented
error, rather than variously crashing or emitting developer-oriented
messages.
This closes a identifiable problem in commits a71cfc56b and
3fb93103a (in v13 and v12), so back-patch into those branches,
along with a test case to try to ensure we don't break it again.
It is not known that any of the former crash cases are reachable
in HEAD, but this seems like a good safety improvement in any case.
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/execTuples.c
M src/test/regress/expected/update.out
M src/test/regress/sql/update.sql
Fix bugs in RETURNING in cross-partition UPDATE cases.
commit : 3fb93103a9fd5182f4f75d6da87dadcb3b36d7b1
author : Tom Lane <[email protected]>
date : Thu, 22 Apr 2021 11:46:41 -0400
committer: Tom Lane <[email protected]>
date : Thu, 22 Apr 2021 11:46:41 -0400
If the source and destination partitions don't have identical
rowtypes (for example, one has dropped columns the other lacks),
then the planSlot contents will be different because of that.
If the query has a RETURNING list that tries to return resjunk
columns out of the planSlot, that is columns from tables that
were joined to the target table, we'd get errors or wrong answers.
That's because we used the RETURNING list generated for the
destination partition, which expects a planSlot matching that
partition's subplan.
The most practical fix seems to be to convert the updated destination
tuple back to the source partition's rowtype, and then apply the
RETURNING list generated for the source partition. This avoids making
fragile assumptions about whether the per-subpartition subplans
generated all the resjunk columns in the same order.
This has been broken since v11 introduced cross-partition UPDATE.
The lack of field complaints shows that non-identical partitions
aren't a common case; therefore, don't stress too hard about
making the conversion efficient.
There's no such bug in HEAD, because commit 86dc90056 got rid of
per-target-relation variance in the contents of the planSlot.
Hence, patch v11-v13 only.
Amit Langote and Etsuro Fujita, small changes by me
Discussion: https://postgr.es/m/CA+HiwqE_UK1jTSNrjb8mpTdivzd3dum6mK--xqKq0Y9VmfwWQA@mail.gmail.com
M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/update.out
M src/test/regress/sql/update.sql
fix silly perl error in commit d064afc720
commit : f7ac005c70588b8bedbe5f1a91848e0d1c9b258d
author : Andrew Dunstan <[email protected]>
date : Wed, 21 Apr 2021 11:12:04 -0400
committer: Andrew Dunstan <[email protected]>
date : Wed, 21 Apr 2021 11:12:04 -0400
M src/test/perl/PostgresNode.pm
Only ever test for non-127.0.0.1 addresses on Windows in PostgresNode
commit : b931304506064b7890c712e4c6d925da59f389d5
author : Andrew Dunstan <[email protected]>
date : Wed, 21 Apr 2021 10:21:22 -0400
committer: Andrew Dunstan <[email protected]>
date : Wed, 21 Apr 2021 10:21:22 -0400
This has been found to cause hangs where tcp usage is forced.
Alexey Kodratov
Discussion: https://postgr.es/m/[email protected]
Backpatch to all live branches
M src/test/perl/PostgresNode.pm
Fix typo in comment
commit : e4fbd11a1d5c291fe719b0bc833882e0baad1f8e
author : Magnus Hagander <[email protected]>
date : Tue, 20 Apr 2021 14:35:16 +0200
committer: Magnus Hagander <[email protected]>
date : Tue, 20 Apr 2021 14:35:16 +0200
Author: Julien Rouhaud
Backpatch-through: 11
Discussion: https://postgr.es/m/20210420121659.odjueyd4rpilorn5@nol
M src/backend/lib/dshash.c
Allow TestLib::slurp_file to skip contents, and use as needed
commit : d380ec9891db13d8a4fc8a40adc68880a88ecb31
author : Andrew Dunstan <[email protected]>
date : Fri, 16 Apr 2021 16:54:04 -0400
committer: Andrew Dunstan <[email protected]>
date : Fri, 16 Apr 2021 16:54:04 -0400
In order to avoid getting old logfile contents certain functions in
PostgresNode were doing one of two things. On Windows it rotated the
logfile and restarted the server, while elsewhere it truncated the log
file. Both of these are unnecessary. We borrow from the buildfarm which
does this instead: note the size of the logfile before we start, and
then when fetching the logfile skip to that position before accumulating
contents. This is spelled differently on Windows but the effect is the
same. This is largely centralized in TestLib's slurp_file function,
which has a new optional parameter, the offset to skip to before
starting to reading the file. Code in the client becomes much neater.
Backpatch to all live branches.
Michael Paquier, slightly modified by me.
Discussion: https://postgr.es/m/[email protected]
M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
doc: Fix typo in example query of SQL/JSON
commit : 26cf32455c501f01d3b73dcf680072169749c980
author : Michael Paquier <[email protected]>
date : Fri, 16 Apr 2021 16:56:29 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 16 Apr 2021 16:56:29 +0900
Author: Erik Rijkers
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M doc/src/sgml/json.sgml
Fix some inappropriately-disallowed uses of ALTER ROLE/DATABASE SET.
commit : a7fcb62852dcf886ef7632ff6b490558c11fca2c
author : Tom Lane <[email protected]>
date : Tue, 13 Apr 2021 15:10:18 -0400
committer: Tom Lane <[email protected]>
date : Tue, 13 Apr 2021 15:10:18 -0400
Most GUC check hooks that inspect database state have special checks
that prevent them from throwing hard errors for state-dependent issues
when source == PGC_S_TEST. This allows, for example,
"ALTER DATABASE d SET default_text_search_config = foo" when the "foo"
configuration hasn't been created yet. Without this, we have problems
during dump/reload or pg_upgrade, because pg_dump has no idea about
possible dependencies of GUC values and can't ensure a safe restore
ordering.
However, check_role() and check_session_authorization() hadn't gotten
the memo about that, and would throw hard errors anyway. It's not
entirely clear what is the use-case for "ALTER ROLE x SET role = y",
but we've now heard two independent complaints about that bollixing
an upgrade, so apparently some people are doing it.
Hence, fix these two functions to act more like other check hooks
with similar needs. (But I did not change their insistence on
being inside a transaction, as it's still not apparent that setting
either GUC from the configuration file would be wise.)
Also fix check_temp_buffers, which had a different form of the disease
of making state-dependent checks without any exception for PGC_S_TEST.
A cursory survey of other GUC check hooks did not find any more issues
of this ilk. (There are a lot of interdependencies among
PGC_POSTMASTER and PGC_SIGHUP GUCs, which may be a bad idea, but
they're not relevant to the immediate concern because they can't be
set via ALTER ROLE/DATABASE.)
Per reports from Charlie Hornsby and Nathan Bossart. Back-patch
to all supported branches.
Discussion: https://postgr.es/m/HE1P189MB0523B31598B0C772C908088DB7709@HE1P189MB0523.EURP189.PROD.OUTLOOK.COM
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/variable.c
M src/backend/utils/misc/guc.c
Redesign the caching done by get_cached_rowtype().
commit : 6530df6c294c3f3b2dba6a1703574f6bbcde0886
author : Tom Lane <[email protected]>
date : Tue, 13 Apr 2021 13:37:07 -0400
committer: Tom Lane <[email protected]>
date : Tue, 13 Apr 2021 13:37:07 -0400
Previously, get_cached_rowtype() cached a pointer to a reference-counted
tuple descriptor from the typcache, relying on the ExprContextCallback
mechanism to release the tupdesc refcount when the expression tree
using the tupdesc was destroyed. This worked fine when it was designed,
but the introduction of within-DO-block COMMITs broke it. The refcount
is logged in a transaction-lifespan resource owner, but plpgsql won't
destroy simple expressions made within the DO block (before its first
commit) until the DO block is exited. That results in a warning about
a leaked tupdesc refcount when the COMMIT destroys the original resource
owner, and then an error about the active resource owner not holding a
matching refcount when the expression is destroyed.
To fix, get rid of the need to have a shutdown callback at all, by
instead caching a pointer to the relevant typcache entry. Those
survive for the life of the backend, so we needn't worry about the
pointer becoming stale. (For registered RECORD types, we can still
cache a pointer to the tupdesc, knowing that it won't change for the
life of the backend.) This mechanism has been in use in plpgsql
and expandedrecord.c since commit 4b93f5799, and seems to work well.
This change requires modifying the ExprEvalStep structs used by the
relevant expression step types, which is slightly worrisome for
back-patching. However, there seems no good reason for extensions
to be familiar with the details of these particular sub-structs.
Per report from Rohit Bhogate. Back-patch to v11 where within-DO-block
COMMITs became a thing.
Discussion: https://postgr.es/m/CAAV6ZkQRCVBh8qAY+SZiHnz+U+FqAGBBDaDTjF2yiKa2nJSLKg@mail.gmail.com
M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/include/executor/execExpr.h
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql
Avoid improbable PANIC during heap_update.
commit : 5f12bc94dcc60403bdfec6ea3d97aa616a512d9e
author : Tom Lane <[email protected]>
date : Tue, 13 Apr 2021 12:17:24 -0400
committer: Tom Lane <[email protected]>
date : Tue, 13 Apr 2021 12:17:24 -0400
heap_update needs to clear any existing "all visible" flag on
the old tuple's page (and on the new page too, if different).
Per coding rules, to do this it must acquire pin on the appropriate
visibility-map page while not holding exclusive buffer lock;
which creates a race condition since someone else could set the
flag whenever we're not holding the buffer lock. The code is
supposed to handle that by re-checking the flag after acquiring
buffer lock and retrying if it became set. However, one code
path through heap_update itself, as well as one in its subroutine
RelationGetBufferForTuple, failed to do this. The end result,
in the unlikely event that a concurrent VACUUM did set the flag
while we're transiently not holding lock, is a non-recurring
"PANIC: wrong buffer passed to visibilitymap_clear" failure.
This has been seen a few times in the buildfarm since recent VACUUM
changes that added code paths that could set the all-visible flag
while holding only exclusive buffer lock. Previously, the flag
was (usually?) set only after doing LockBufferForCleanup, which
would insist on buffer pin count zero, thus preventing the flag
from becoming set partway through heap_update. However, it's
clear that it's heap_update not VACUUM that's at fault here.
What's less clear is whether there is any hazard from these bugs
in released branches. heap_update is certainly violating API
expectations, but if there is no code path that can set all-visible
without a cleanup lock then it's only a latent bug. That's not
100% certain though, besides which we should worry about extensions
or future back-patch fixes that could introduce such code paths.
I chose to back-patch to v12. Fixing RelationGetBufferForTuple
before that would require also back-patching portions of older
fixes (notably 0d1fe9f74), which is more code churn than seems
prudent to fix a hypothetical issue.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/heap/heapam.c
M src/backend/access/heap/hio.c
Use "-I." in directories holding Bison parsers, for Oracle compilers.
commit : 4749c7ff4932ca593fcde9928904155642c0b496
author : Noah Misch <[email protected]>
date : Mon, 12 Apr 2021 19:24:41 -0700
committer: Noah Misch <[email protected]>
date : Mon, 12 Apr 2021 19:24:41 -0700
With the Oracle Developer Studio 12.6 compiler, #line directives alter
the current source file location for purposes of #include "..."
directives. Hence, a VPATH build failed with 'cannot find include file:
"specscanner.c"'. With two exceptions, parser-containing directories
already add "-I. -I$(srcdir)"; eliminate the exceptions. Back-patch to
9.6 (all supported versions).
M src/backend/utils/adt/Makefile
M src/test/isolation/Makefile
Port regress-python3-mangle.mk to Solaris "sed".
commit : e3ac7d17616b6baea12d21e3a0b32c683b81f9a6
author : Noah Misch <[email protected]>
date : Mon, 12 Apr 2021 19:24:21 -0700
committer: Noah Misch <[email protected]>
date : Mon, 12 Apr 2021 19:24:21 -0700
It doesn't support "\(foo\)*" like a POSIX "sed" implementation does;
see the Autoconf manual. Back-patch to 9.6 (all supported versions).
M src/pl/plpython/regress-python3-mangle.mk
Fix old bug with coercing the result of a COLLATE expression.
commit : 27011bcffa74a5113c9b5408c678315e74fb9a70
author : Tom Lane <[email protected]>
date : Mon, 12 Apr 2021 14:37:22 -0400
committer: Tom Lane <[email protected]>
date : Mon, 12 Apr 2021 14:37:22 -0400
There are hacks in parse_coerce.c to push down a requested coercion
to below any CollateExpr that may appear. However, we did that even
if the requested data type is non-collatable, leading to an invalid
expression tree in which CollateExpr is applied to a non-collatable
type. The fix is just to drop the CollateExpr altogether, reasoning
that it's useless.
This bug is ten years old, dating to the original addition of
COLLATE support. The lack of field complaints suggests that there
aren't a lot of user-visible consequences. We noticed the problem
because it would trigger an assertion in DefineVirtualRelation if
the invalid structure appears as an output column of a view; however,
in a non-assert build, you don't see a crash just a (subtly incorrect)
complaint about applying collation to a non-collatable type. I found
that by putting the incorrect structure further down in a view, I could
make a view definition that would fail dump/reload, per the added
regression test case. But CollateExpr doesn't do anything at run-time,
so this likely doesn't lead to any really exciting consequences.
Per report from Yulin Pei. Back-patch to all supported branches.
Discussion: https://postgr.es/m/HK0PR01MB22744393C474D503E16C8509F4709@HK0PR01MB2274.apcprd01.prod.exchangelabs.com
M src/backend/parser/parse_coerce.c
M src/test/regress/expected/collate.out
M src/test/regress/sql/collate.sql
Fix out-of-bound memory access for interval -> char conversion
commit : 82dd5706ee5a5fc4db962fe1a672b4f71ab51612
author : Michael Paquier <[email protected]>
date : Mon, 12 Apr 2021 11:31:30 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 12 Apr 2021 11:31:30 +0900
Using Roman numbers (via "RM" or "rm") for a conversion to calculate a
number of months has never considered the case of negative numbers,
where a conversion could easily cause out-of-bound memory accesses. The
conversions in themselves were not completely consistent either, as
specifying 12 would result in NULL, but it should mean XII.
This commit reworks the conversion calculation to have a more
consistent behavior:
- If the number of months and years is 0, return NULL.
- If the number of months is positive, return the exact month number.
- If the number of months is negative, do a backward calculation, with
-1 meaning December, -2 November, etc.
Reported-by: Theodor Arsenij Larionov-Trichkin
Author: Julien Rouhaud
Discussion: https://postgr.es/m/[email protected]
backpatch-through: 9.6
M src/backend/utils/adt/formatting.c
M src/test/regress/expected/timestamp.out
M src/test/regress/sql/timestamp.sql
Fix typo
commit : 2bf44fbe271dae3f4bd458e19e32d51996b988b4
author : Magnus Hagander <[email protected]>
date : Fri, 9 Apr 2021 12:40:14 +0200
committer: Magnus Hagander <[email protected]>
date : Fri, 9 Apr 2021 12:40:14 +0200
Author: Daniel Westermann
Backpatch-through: 9.6
Discussion: https://postgr.es/m/GV0P278MB0483A7AA85BAFCC06D90F453D2739@GV0P278MB0483.CHEP278.PROD.OUTLOOK.COM
M src/backend/utils/misc/guc.c
Fix typos and grammar in documentation and code comments
commit : d42978c67afa930b1208caa9555024da10550cdb
author : Michael Paquier <[email protected]>
date : Fri, 9 Apr 2021 13:53:22 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 9 Apr 2021 13:53:22 +0900
Comment fixes are applied on HEAD, and documentation improvements are
applied on back-branches where needed.
Author: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M doc/src/sgml/maintenance.sgml
M doc/src/sgml/ref/create_table.sgml
M doc/src/sgml/ref/createuser.sgml
Don't add non-existent pages to bitmap from BRIN
commit : 847612fda6f6da88441f4c823ebcbf8474bfe0b7
author : Tomas Vondra <[email protected]>
date : Wed, 7 Apr 2021 15:58:35 +0200
committer: Tomas Vondra <[email protected]>
date : Wed, 7 Apr 2021 15:58:35 +0200
The code in bringetbitmap() simply added the whole matching page range
to the TID bitmap, as determined by pages_per_range, even if some of the
pages were beyond the end of the heap. The query then might fail with
an error like this:
ERROR: could not open file "base/20176/20228.2" (target block
262144): previous segment is only 131021 blocks
In this case, the relation has 262093 pages (131072 and 131021 pages),
but we're trying to acess block 262144, i.e. first block of the 3rd
segment. At that point _mdfd_getseg() notices the preceding segment is
incomplete, and fails.
Hitting this in practice is rather unlikely, because:
* Most indexes use power-of-two ranges, so segments and page ranges
align perfectly (segment end is also a page range end).
* The table size has to be just right, with the last segment being
almost full - less than one page range from full segment, so that the
last page range actually crosses the segment boundary.
* Prefetch has to be enabled. The regular page access checks that
pages are not beyond heap end, but prefetch does not. On older
releases (before 12) the execution stops after hitting the first
non-existent page, so the prefetch distance has to be sufficient
to reach the first page in the next segment to trigger the issue.
Since 12 it's enough to just have prefetch enabled, the prefetch
distance does not matter.
Fixed by not adding non-existent pages to the TID bitmap. Backpatch
all the way back to 9.6 (BRIN indexes were introduced in 9.5, but that
release is EOL).
Backpatch-through: 9.6
M src/backend/access/brin/brin.c
Fix potential rare failure in the kerberos TAP tests
commit : 92273d48771a76fdd8e8d8f7fd7b7f6dcfb86d92
author : Michael Paquier <[email protected]>
date : Wed, 7 Apr 2021 19:59:27 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 7 Apr 2021 19:59:27 +0900
Instead of writing a query to psql's stdin, which can cause a failure
where psql exits before writing, reporting a write failure with a broken
pipe, this changes the logic to use -c. This was not seen in the
buildfarm as no animals with a sensitive environment are running the
kerberos tests, but let's be safe.
HEAD is able to handle the situation as of 6d41dd0 for all the test
suites doing connection checks. f44b9b6 has fixed the same problem for
the LDAP tests.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 11
M src/test/kerberos/t/001_auth.pl
Shut down transaction tracking at startup process exit.
commit : dd5b7e486a4f90b54db62e57b84b81003c0d032d
author : Fujii Masao <[email protected]>
date : Tue, 6 Apr 2021 02:25:37 +0900
committer: Fujii Masao <[email protected]>
date : Tue, 6 Apr 2021 02:25:37 +0900
Maxim Orlov reported that the shutdown of standby server could result in
the following assertion failure. The cause of this issue was that,
when the shutdown caused the startup process to exit, recovery-time
transaction tracking was not shut down even if it's already initialized,
and some locks the tracked transactions were holding could not be released.
At this situation, if other process was invoked and the PGPROC entry that
the startup process used was assigned to it, it found such unreleased locks
and caused the assertion failure, during the initialization of it.
TRAP: FailedAssertion("SHMQueueEmpty(&(MyProc->myProcLocks[i]))"
This commit fixes this issue by making the startup process shut down
transaction tracking and release all locks, at the exit of it.
Back-patch to all supported branches.
Reported-by: Maxim Orlov
Author: Fujii Masao
Reviewed-by: Maxim Orlov
Discussion: https://postgr.es/m/[email protected]
M src/backend/postmaster/startup.c
M src/backend/storage/ipc/standby.c
Fix more confusion in SP-GiST.
commit : 48b319e87636aebcce05f06b02c7feb7ceb9e9a1
author : Tom Lane <[email protected]>
date : Sun, 4 Apr 2021 17:57:07 -0400
committer: Tom Lane <[email protected]>
date : Sun, 4 Apr 2021 17:57:07 -0400
spg_box_quad_leaf_consistent unconditionally returned the leaf
datum as leafValue, even though in its usage for poly_ops that
value is of completely the wrong type.
In versions before 12, that was harmless because the core code did
nothing with leafValue in non-index-only scans ... but since commit
2a6368343, if we were doing a KNN-style scan, spgNewHeapItem would
unconditionally try to copy the value using the wrong datatype
parameters. Said copying is a waste of time and space if we're not
going to return the data, but it accidentally failed to fail until
I fixed the datatype confusion in ac9099fc1.
Hence, change spgNewHeapItem to not copy the datum unless we're
actually going to return it later. This saves cycles and dodges
the question of whether lossy opclasses are returning the right
type. Also change spg_box_quad_leaf_consistent to not return
data that might be of the wrong type, as insurance against
somebody introducing a similar bug into the core code in future.
It seems like a good idea to back-patch these two changes into
v12 and v13, although I'm afraid to change spgNewHeapItem's
mistaken idea of which datatype to use in those branches.
Per buildfarm results from ac9099fc1.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/spgist/spgscan.c
M src/backend/utils/adt/geo_spgist.c
Use macro MONTHS_PER_YEAR instead of '12' in /ecpg/pgtypeslib
commit : 6972d9104b6c54bae2fd63d8e02e9c014d162ca3
author : Bruce Momjian <[email protected]>
date : Fri, 2 Apr 2021 16:42:29 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 2 Apr 2021 16:42:29 -0400
All other places already use MONTHS_PER_YEAR appropriately.
Backpatch-through: 9.6
M src/interfaces/ecpg/pgtypeslib/interval.c
Clarify documentation of RESET ROLE
commit : 53f5c2df05368bade3523d440f5c10cfae6ad5ef
author : Joe Conway <[email protected]>
date : Fri, 2 Apr 2021 13:48:48 -0400
committer: Joe Conway <[email protected]>
date : Fri, 2 Apr 2021 13:48:48 -0400
Command-line options, or previous "ALTER (ROLE|DATABASE) ...
SET ROLE ..." commands, can change the value of the default role
for a session. In the presence of one of these, RESET ROLE will
change the current user identifier to the default role rather
than the session user identifier. Fix the documentation to
reflect this reality. Backpatch to all supported versions.
Author: Nathan Bossart
Reviewed-By: Laurenz Albe, David G. Johnston, Joe Conway
Reported by: Nathan Bossart
Discussion: https://postgr.es/m/flat/925134DB-8212-4F60-8AB1-B1231D750CB4%40amazon.com
Backpatch-through: 9.6
M doc/src/sgml/ref/set_role.sgml
pg_checksums: Fix progress reporting.
commit : 24bcce3bd6b458d0d2b064c2ab2ed2837c1211a3
author : Fujii Masao <[email protected]>
date : Sat, 3 Apr 2021 00:07:00 +0900
committer: Fujii Masao <[email protected]>
date : Sat, 3 Apr 2021 00:07:00 +0900
pg_checksums uses two counters, total size and current size,
to calculate the progress. Previously the progress that
pg_checksums reported could not reach 100% at the end.
The cause of this issue was that the sizes of only pages excluding
new ones in each file were counted as the current size
while the size of each file is counted as the total size.
That is, the total size of all new pages could be reported
as the difference between the total size and current size.
This commit fixes this issue by making pg_checksums count
the sizes of all pages including new ones in each file as
the current size.
Back-patch to v12 where progress reporting was added to pg_checksums.
Reported-by: Shinya Kato
Author: Shinya Kato
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/TYAPR01MB289656B1ACA0A5E7CAD07BE3C47A9@TYAPR01MB2896.jpnprd01.prod.outlook.com
M src/bin/pg_checksums/pg_checksums.c
doc: Clarify how to generate backup files with non-exclusive backups
commit : 677357047b9c920e351b73d9670a813fcdc6801b
author : Michael Paquier <[email protected]>
date : Fri, 2 Apr 2021 16:37:11 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 2 Apr 2021 16:37:11 +0900
The current instructions describing how to write the backup_label and
tablespace_map files are confusing. For example, opening a file in text
mode on Windows and copy-pasting the file's contents would result in a
failure at recovery because of the extra CRLF characters generated. The
documentation was not stating that clearly, and per discussion this is
not considered as a supported scenario.
This commit extends a bit the documentation to mention that it may be
required to open the file in binary mode before writing its data.
Reported-by: Wang Shenhao
Author: David Steele
Reviewed-by: Andrew Dunstan, Magnus Hagander
Discussion: https://postgr.es/m/8373f61426074f2cb6be92e02f838389@G08CNEXMBPEKD06.g08.fujitsu.local
Backpatch-through: 9.6
M doc/src/sgml/backup.sgml
doc: mention that intervening major releases can be skipped
commit : d6ca789dde70f2c323b79559b8ce0746ddf7a48d
author : Bruce Momjian <[email protected]>
date : Thu, 1 Apr 2021 21:17:24 -0400
committer: Bruce Momjian <[email protected]>
date : Thu, 1 Apr 2021 21:17:24 -0400
Also mention that you should read the intervening major releases notes.
This change was also applied to the website.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M doc/src/sgml/runtime.sgml
Improve stability of test with vacuum_truncate in reloptions.sql
commit : bada6280f0b98765ecad8d85063cddf6ce82b3b0
author : Michael Paquier <[email protected]>
date : Fri, 2 Apr 2021 09:44:54 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 2 Apr 2021 09:44:54 +0900
This test has been using a simple VACUUM with pg_relation_size() to
check if a relation gets physically truncated or not, but forgot the
fact that some concurrent activity, like checkpoint buffer writes, could
cause some pages to be skipped. The second test enabling
vacuum_truncate could fail, seeing a non-empty relation. The first test
would not have failed, but could finish by testing a behavior different
than the one aimed for. Both tests gain a FREEZE option, to make the
vacuums more aggressive and prevent page skips.
This is similar to the issues fixed in c2dc1a7.
Author: Arseny Sher
Reviewed-by: Masahiko Sawada
Discussion: https://postgr.es/m/87tuotr2hh.fsf@ars-thinkpad
backpatch-through: 12
M src/test/regress/expected/reloptions.out
M src/test/regress/sql/reloptions.sql
Fix pg_restore's misdesigned code for detecting archive file format.
commit : 84c5e0dd2e7344d36d5c3a32228b35a284ef1a1a
author : Tom Lane <[email protected]>
date : Thu, 1 Apr 2021 13:34:16 -0400
committer: Tom Lane <[email protected]>
date : Thu, 1 Apr 2021 13:34:16 -0400
Despite the clear comments pointing out that the duplicative code
segments in ReadHead() and _discoverArchiveFormat() needed to be
in sync, they were not: the latter did not bother to apply any of
the sanity checks in the former. We'd missed noticing this partly
because none of those checks would fail in scenarios we customarily
test, and partly because the oversight would be masked if both
segments execute, which they would in cases other than needing to
autodetect the format of a non-seekable stdin source. However,
in a case meeting all these requirements --- for example, trying
to read a newer-than-supported archive format from non-seekable
stdin --- pg_restore missed applying the version check and would
likely dump core or otherwise misbehave.
The whole thing is silly anyway, because there seems little reason
to duplicate the logic beyond the one-line verification that the
file starts with "PGDMP". There seems to have been an undocumented
assumption that multiple major formats (major enough to require
separate reader modules) would nonetheless share the first half-dozen
fields of the custom-format header. This seems unlikely, so let's
fix it by just nuking the duplicate logic in _discoverArchiveFormat().
Also get rid of the pointless attempt to seek back to the start of
the file after successful autodetection. That wastes cycles and
it means we have four behaviors to verify not two.
Per bug #16951 from Sergey Koposov. This has been broken for
decades, so back-patch to all supported versions.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_archiver.h
M src/bin/pg_dump/pg_backup_tar.c
doc: Clarify use of ACCESS EXCLUSIVE lock in various sections
commit : a126a9510def33fedcddf6288ae431f8d6f2f85c
author : Michael Paquier <[email protected]>
date : Thu, 1 Apr 2021 15:28:56 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 1 Apr 2021 15:28:56 +0900
Some sections of the documentation used "exclusive lock" to describe
that an ACCESS EXCLUSIVE lock is taken during a given operation. This
can be confusing to the reader as ACCESS SHARE is allowed with an
EXCLUSIVE lock is used, but that would not be the case with what is
described on those parts of the documentation.
Author: Greg Rychlewski
Discussion: https://postgr.es/m/CAKemG7VptD=7fNWckFMsMVZL_zzvgDO6v2yVmQ+ZiBfc_06kCQ@mail.gmail.com
Backpatch-through: 9.6
M doc/src/sgml/ddl.sgml
M doc/src/sgml/hstore.sgml
M doc/src/sgml/indexam.sgml
M doc/src/sgml/maintenance.sgml
M doc/src/sgml/mvcc.sgml
M doc/src/sgml/pgrowlocks.sgml
M doc/src/sgml/ref/drop_index.sgml
M doc/src/sgml/ref/reindex.sgml
M doc/src/sgml/ref/vacuum.sgml
Add a docs section for obsoleted and renamed functions and settings
commit : 448e86c3345bb41d3e530ab204b8f59301cdfb36
author : Stephen Frost <[email protected]>
date : Wed, 31 Mar 2021 16:23:13 -0400
committer: Stephen Frost <[email protected]>
date : Wed, 31 Mar 2021 16:23:13 -0400
The new appendix groups information on renamed or removed settings,
commands, etc into an out-of-the-way part of the docs.
The original id elements are retained in each subsection to ensure that
the same filenames are produced for HTML docs. This prevents /current/
links on the web from breaking, and allows users of the web docs
to follow links from old version pages to info on the changes in the
new version. Prior to this change, a link to /current/ for renamed
sections like the recovery.conf docs would just 404. Similarly if
someone searched for recovery.conf they would find the pg11 docs,
but there would be no /12/ or /current/ link, so they couldn't easily
find out that it was removed in pg12 or how to adapt.
Index entries are also added so that there's a breadcrumb trail for
users to follow when they know the old name, but not what we changed it
to. So a user who is trying to find out how to set standby_mode in
PostgreSQL 12+, or where pg_resetxlog went, now has more chance of
finding that information.
Craig Ringer and Stephen Frost
Reviewed-by: Euler Taveira
Discussion: https://postgr.es/m/CAGRY4nzPNOyYQ_1-pWYToUVqQ0ThqP5jdURnJMZPm539fdizOg%40mail.gmail.com
Backpatch-through: 10
A doc/src/sgml/appendix-obsolete-pgreceivexlog.sgml
A doc/src/sgml/appendix-obsolete-pgresetxlog.sgml
A doc/src/sgml/appendix-obsolete-pgxlogdump.sgml
A doc/src/sgml/appendix-obsolete-recovery-config.sgml
A doc/src/sgml/appendix-obsolete.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/filelist.sgml
M doc/src/sgml/high-availability.sgml
M doc/src/sgml/postgres.sgml
M doc/src/sgml/ref/pg_basebackup.sgml
Update obsolete comment.
commit : cf8384ac8333dea9742b754d998491a321269704
author : Etsuro Fujita <[email protected]>
date : Tue, 30 Mar 2021 13:00:03 +0900
committer: Etsuro Fujita <[email protected]>
date : Tue, 30 Mar 2021 13:00:03 +0900
Back-patch to all supported branches.
Author: Etsuro Fujita
Discussion: https://postgr.es/m/CAPmGK17DwzaSf%2BB71dhL2apXdtG-OmD6u2AL9Cq2ZmAR0%2BzapQ%40mail.gmail.com
M contrib/postgres_fdw/postgres_fdw.c
doc: Define TLS as an acronym
commit : 3c3221a138413bf04d86a815733c321849792bd8
author : Stephen Frost <[email protected]>
date : Sun, 28 Mar 2021 11:28:15 -0400
committer: Stephen Frost <[email protected]>
date : Sun, 28 Mar 2021 11:28:15 -0400
Commit c6763156589 added an acronym reference for "TLS" but the definition
was never added.
Author: Daniel Gustafsson
Reviewed-by: Michael Paquier
Backpatch-through: 9.6
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/acronyms.sgml
Fix ndistinct estimates with system attributes
commit : 88acb0135720076599308e6fd58b659c81d1beba
author : Tomas Vondra <[email protected]>
date : Fri, 26 Mar 2021 22:34:53 +0100
committer: Tomas Vondra <[email protected]>
date : Fri, 26 Mar 2021 22:34:53 +0100
When estimating the number of groups using extended statistics, the code
was discarding information about system attributes. This led to strange
situation that
SELECT 1 FROM t GROUP BY ctid;
could have produced higher estimate (equal to pg_class.reltuples) than
SELECT 1 FROM t GROUP BY a, b, ctid;
with extended statistics on (a,b). Fixed by retaining information about
the system attribute.
Backpatch all the way to 10, where extended statistics were introduced.
Author: Tomas Vondra
Backpatch-through: 10
M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/stats_ext.out
Document lock obtained during partition detach
commit : 366aa374b315667fe44480ec8934cb1034ba0930
author : Alvaro Herrera <[email protected]>
date : Thu, 25 Mar 2021 16:30:22 -0300
committer: Alvaro Herrera <[email protected]>
date : Thu, 25 Mar 2021 16:30:22 -0300
On partition detach, we acquire a SHARE lock on all tables that
reference the partitioned table that we're detaching a partition from,
but failed to document this fact. My oversight in commit f56f8f8da6af.
Repair. Backpatch to 12.
Author: Álvaro Herrera <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/alter_table.sgml
Remove StoreSingleInheritance reimplementation
commit : 292b7d9ffa18dfdf2c90efd4f14bbd196ebad76f
author : Alvaro Herrera <[email protected]>
date : Thu, 25 Mar 2021 10:47:38 -0300
committer: Alvaro Herrera <[email protected]>
date : Thu, 25 Mar 2021 10:47:38 -0300
I introduced this duplicate code in commit 8b08f7d4820f for no good
reason. Remove it, and backpatch to 11 where it was introduced.
Author: Álvaro Herrera <[email protected]>
M src/backend/commands/indexcmds.c
Fix bug in WAL replay of COMMIT_TS_SETTS record.
commit : 73cce168ffcb1a0343cfa6fafe237f49b1449734
author : Fujii Masao <[email protected]>
date : Thu, 25 Mar 2021 11:23:30 +0900
committer: Fujii Masao <[email protected]>
date : Thu, 25 Mar 2021 11:23:30 +0900
Previously the WAL replay of COMMIT_TS_SETTS record called
TransactionTreeSetCommitTsData() with the argument write_xlog=true,
which generated and wrote new COMMIT_TS_SETTS record.
This should not be acceptable because it's during recovery.
This commit fixes the WAL replay of COMMIT_TS_SETTS record
so that it calls TransactionTreeSetCommitTsData() with write_xlog=false
and doesn't generate new WAL during recovery.
Back-patch to all supported branches.
Reported-by: lx zou <[email protected]>
Author: Fujii Masao
Reviewed-by: Alvaro Herrera
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/commit_ts.c
Fix psql's \connect command some more.
commit : beac4bd65dcf02a86013120c660498e50f3f88dd
author : Tom Lane <[email protected]>
date : Tue, 23 Mar 2021 14:27:50 -0400
committer: Tom Lane <[email protected]>
date : Tue, 23 Mar 2021 14:27:50 -0400
Jasen Betts reported yet another unintended side effect of commit
85c54287a: reconnecting with "\c service=whatever" did not have the
expected results. The reason is that starting from the output of
PQconndefaults() effectively allows environment variables (such
as PGPORT) to override entries in the service file, whereas the
normal priority is the other way around.
Not using PQconndefaults at all would require yet a third main code
path in do_connect's parameter setup, so I don't really want to fix
it that way. But we can have the logic effectively ignore all the
default values for just a couple more lines of code.
This patch doesn't change the behavior for "\c -reuse-previous=on
service=whatever". That remains significantly different from before
85c54287a, because many more parameters will be re-used, and thus
not be possible for service entries to replace. But I think this
is (mostly?) intentional. In any case, since libpq does not report
where it got parameter values from, it's hard to do differently.
Per bug #16936 from Jasen Betts. As with the previous patches,
back-patch to all supported branches. (9.5 is unfortunately now
out of support, so this won't get fixed there.)
Discussion: https://postgr.es/m/[email protected]
M src/bin/psql/command.c
Use correct spelling of statistics kind
commit : 1c457b8b5194bb838b61b02c883ddac4a212ea7e
author : Tomas Vondra <[email protected]>
date : Tue, 23 Mar 2021 04:51:53 +0100
committer: Tomas Vondra <[email protected]>
date : Tue, 23 Mar 2021 04:51:53 +0100
A couple error messages and comments used 'statistic kind', not the
correct 'statistics kind'. Fix and backpatch all the way back to 10,
where extended statistics were introduced.
Backpatch-through: 10
M doc/src/sgml/catalogs.sgml
M src/backend/statistics/dependencies.c
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
M src/backend/statistics/mvdistinct.c
M src/include/nodes/pathnodes.h
pg_waldump: Fix bug in per-record statistics.
commit : 4220e06f4c0c597c77e0170b4032c3cd10fb9555
author : Fujii Masao <[email protected]>
date : Tue, 23 Mar 2021 09:53:08 +0900
committer: Fujii Masao <[email protected]>
date : Tue, 23 Mar 2021 09:53:08 +0900
pg_waldump --stats=record identifies a record by a combination
of the RmgrId and the four bits of the xl_info field of the record.
But XACT records use the first bit of those four bits for an optional
flag variable, and the following three bits for the opcode to
identify a record. So previously the same type of XACT record
could have different four bits (three bits are the same but the
first one bit is different), and which could cause
pg_waldump --stats=record to show two lines of per-record statistics
for the same XACT record. This is a bug.
This commit changes pg_waldump --stats=record so that it processes
only XACT record differently, i.e., filters the opcode out of xl_info
and uses a combination of the RmgrId and those three bits as
the identifier of a record, only for XACT record. For other records,
the four bits of the xl_info field are still used.
Back-patch to all supported branches.
Author: Kyotaro Horiguchi
Reviewed-by: Shinya Kato, Fujii Masao
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_waldump/pg_waldump.c
Fix new TAP test for 2PC transactions and PITRs on Windows
commit : c0849e41322d4e791e78a3990f8f3ccc437c8006
author : Michael Paquier <[email protected]>
date : Mon, 22 Mar 2021 09:51:19 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 22 Mar 2021 09:51:19 +0900
The test added by 595b9cb forgot that on Windows it is necessary to set
up pg_hba.conf (see PostgresNode::set_replication_conf) with a specific
entry or base backups fail. Any node that requires to support
replication just needs to pass down allows_streaming at initialization.
This updates the test to do so. Simplify things a bit while on it.
Per buildfarm member fairywren. Any Windows hosts running this test
would have failed, and I have reproduced the problem as well.
Backpatch-through: 10
M src/test/recovery/t/023_pitr_prepared_xact.pl
Fix timeline assignment in checkpoints with 2PC transactions
commit : 4b1dd9b1ea75bc57d00f691f0dcf80e4eca91dc0
author : Michael Paquier <[email protected]>
date : Mon, 22 Mar 2021 08:31:05 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 22 Mar 2021 08:31:05 +0900
Any transactions found as still prepared by a checkpoint have their
state data read from the WAL records generated by PREPARE TRANSACTION
before being moved into their new location within pg_twophase/. While
reading such records, the WAL reader uses the callback
read_local_xlog_page() to read a page, that is shared across various
parts of the system. This callback, since 1148e22a, has introduced an
update of ThisTimeLineID when reading a record while in recovery, which
is potentially helpful in the context of cascading WAL senders.
This update of ThisTimeLineID interacts badly with the checkpointer if a
promotion happens while some 2PC data is read from its record, as, by
changing ThisTimeLineID, any follow-up WAL records would be written to
an timeline older than the promoted one. This results in consistency
issues. For instance, a subsequent server restart would cause a failure
in finding a valid checkpoint record, resulting in a PANIC, for
instance.
This commit changes the code reading the 2PC data to reset the timeline
once the 2PC record has been read, to prevent messing up with the static
state of the checkpointer. It would be tempting to do the same thing
directly in read_local_xlog_page(). However, based on the discussion
that has led to 1148e22a, users may rely on the updates of
ThisTimeLineID when a WAL record page is read in recovery, so changing
this callback could break some cases that are working currently.
A TAP test reproducing the issue is added, relying on a PITR to
precisely trigger a promotion with a prepared transaction still
tracked.
Per discussion with Heikki Linnakangas, Kyotaro Horiguchi, Fujii Masao
and myself.
Author: Soumyadeep Chakraborty, Jimmy Yih, Kevin Yeap
Discussion: https://postgr.es/m/CAE-ML+_EjH_fzfq1F3RJ1=XaaNG=-Jz-i3JqkNhXiLAsM3z-Ew@mail.gmail.com
Backpatch-through: 10
M src/backend/access/transam/twophase.c
A src/test/recovery/t/023_pitr_prepared_xact.pl
Fix memory leak when rejecting bogus DH parameters.
commit : 2f31414f4322876b34674eedc6e7d19c29ebe0d0
author : Tom Lane <[email protected]>
date : Sat, 20 Mar 2021 12:47:21 -0400
committer: Tom Lane <[email protected]>
date : Sat, 20 Mar 2021 12:47:21 -0400
While back-patching e0e569e1d, I noted that there were some other
places where we ought to be applying DH_free(); namely, where we
load some DH parameters from a file and then reject them as not
being sufficiently secure. While it seems really unlikely that
anybody would hit these code paths in production, let alone do
so repeatedly, let's fix it for consistency.
Back-patch to v10 where this code was introduced.
Discussion: https://postgr.es/m/[email protected]
M src/backend/libpq/be-secure-openssl.c
Fix memory leak when initializing DH parameters in backend
commit : 992cba94d38ef20765e4c54e4dff00ae8a58a6c5
author : Tom Lane <[email protected]>
date : Sat, 20 Mar 2021 12:38:22 -0400
committer: Tom Lane <[email protected]>
date : Sat, 20 Mar 2021 12:38:22 -0400
When loading DH parameters used for the generation of ephemeral DH keys
in the backend, the code has never bothered releasing the memory used
for the DH information loaded from a file or from libpq's default. This
commit makes sure that the information is properly free()'d.
Back-patch of e0e569e1d. We originally thought the leak was minor and
not worth back-patching, but Jelte Fennema pointed out that repeated
SIGHUP's can result in very serious bloat of the postmaster, which is
then multiplied by being duplicated into eadh forked child.
Back-patch to v10; the code looked different before c0a15e07c,
and didn't have a leak in the actually-live code paths.
Michael Paquier
Discussion: https://postgr.es/m/[email protected]
M src/backend/libpq/be-secure-openssl.c
Don't leak malloc'd error string in libpqrcv_check_conninfo().
commit : 4eca51d4464133e6f4cd923355c6dd971d9c27d3
author : Tom Lane <[email protected]>
date : Thu, 18 Mar 2021 22:21:58 -0400
committer: Tom Lane <[email protected]>
date : Thu, 18 Mar 2021 22:21:58 -0400
We leaked the error report from PQconninfoParse, when there was
one. It seems unlikely that real usage patterns would repeat
the failure often enough to create serious bloat, but let's
back-patch anyway to keep the code similar in all branches.
Found via valgrind testing.
Back-patch to v10 where this code was added.
Discussion: https://postgr.es/m/[email protected]
M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
Don't leak malloc'd strings when a GUC setting is rejected.
commit : fc552f8680a79d602beae230615ffe8ed236cc43
author : Tom Lane <[email protected]>
date : Thu, 18 Mar 2021 22:09:41 -0400
committer: Tom Lane <[email protected]>
date : Thu, 18 Mar 2021 22:09:41 -0400
Because guc.c prefers to keep all its string values in malloc'd
not palloc'd storage, it has to be more careful than usual to
avoid leaks. Error exits out of string GUC hook checks failed
to clear the proposed value string, and error exits out of
ProcessGUCArray() failed to clear the malloc'd results of
ParseLongOption().
Found via valgrind testing.
This problem is ancient, so back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/misc/guc.c
Don't leak compiled regex(es) when an ispell cache entry is dropped.
commit : 92bc14a1027d9da079264c71329b87e137878845
author : Tom Lane <[email protected]>
date : Thu, 18 Mar 2021 21:44:43 -0400
committer: Tom Lane <[email protected]>
date : Thu, 18 Mar 2021 21:44:43 -0400
The text search cache mechanisms assume that we can clean up
an invalidated dictionary cache entry simply by resetting the
associated long-lived memory context. However, that does not work
for ispell affixes that make use of regular expressions, because
the regex library deals in plain old malloc. Hence, we leaked
compiled regex(es) any time we dropped such a cache entry. That
could quickly add up, since even a fairly trivial regex can use up
tens of kB, and a large one can eat megabytes. Add a memory context
callback to ensure that a regex gets freed when its owning cache
entry is cleared.
Found via valgrind testing.
This problem is ancient, so back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/tsearch/spell.c
M src/include/tsearch/dicts/spell.h
Don't run RelationInitTableAccessMethod in a long-lived context.
commit : 1452a0bb87c78812372f103de14cb6492a932ac6
author : Tom Lane <[email protected]>
date : Thu, 18 Mar 2021 20:50:56 -0400
committer: Tom Lane <[email protected]>
date : Thu, 18 Mar 2021 20:50:56 -0400
Some code paths in this function perform syscache lookups, which
can lead to table accesses and possibly leakage of cruft into
the caller's context. If said context is CacheMemoryContext,
we eventually will have visible bloat. But fixing this is no
harder than moving one memory context switch step. (The other
callers don't have a problem.)
Andres Freund and I independently found this via valgrind testing.
Back-patch to v12 where this code was added.
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/cache/relcache.c
Don't leak rd_statlist when a relcache entry is dropped.
commit : fbcc9fe33c43a3fb79812b72960df4909a4551e5
author : Tom Lane <[email protected]>
date : Thu, 18 Mar 2021 20:37:09 -0400
committer: Tom Lane <[email protected]>
date : Thu, 18 Mar 2021 20:37:09 -0400
Although these lists are usually NIL, and even when not empty
are unlikely to be large, constant relcache update traffic could
eventually result in visible bloat of CacheMemoryContext.
Found via valgrind testing.
Back-patch to v10 where this field was added.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/cache/relcache.c
Fix function name in error hint
commit : a5eb70cfca5bc252d7913eb6bb0ff304c4b7d7ae
author : Magnus Hagander <[email protected]>
date : Thu, 18 Mar 2021 11:23:48 +0100
committer: Magnus Hagander <[email protected]>
date : Thu, 18 Mar 2021 11:23:48 +0100
pg_read_file() is the function that's in core, pg_file_read() is in
adminpack. But when using pg_file_read() in adminpack it calls the *C*
level function pg_read_file() in core, which probably threw the original
author off. But the error hint should be about the SQL function.
Reported-By: Sergei Kornilov
Backpatch-through: 11
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/genfile.c
Prevent buffer overrun in read_tablespace_map().
commit : 2111b409879eee6900aaa3107987f932524064ca
author : Tom Lane <[email protected]>
date : Wed, 17 Mar 2021 16:10:38 -0400
committer: Tom Lane <[email protected]>
date : Wed, 17 Mar 2021 16:10:38 -0400
Robert Foggia of Trustwave reported that read_tablespace_map()
fails to prevent an overrun of its on-stack input buffer.
Since the tablespace map file is presumed trustworthy, this does
not seem like an interesting security vulnerability, but still
we should fix it just in the name of robustness.
While here, document that pg_basebackup's --tablespace-mapping option
doesn't work with tar-format output, because it doesn't. To make it
work, we'd have to modify the tablespace_map file within the tarball
sent by the server, which might be possible but I'm not volunteering.
(Less-painful solutions would require changing the basebackup protocol
so that the source server could adjust the map. That's not very
appetizing either.)
M doc/src/sgml/ref/pg_basebackup.sgml
M src/backend/access/transam/xlog.c
Revert "Fix race in Parallel Hash Join batch cleanup."
commit : b9ed85698f3e101bc84eb9b1adf77f5d04ebe7eb
author : Thomas Munro <[email protected]>
date : Thu, 18 Mar 2021 01:06:01 +1300
committer: Thomas Munro <[email protected]>
date : Thu, 18 Mar 2021 01:06:01 +1300
This reverts commit 8fa2478b407ef867d501fafcdea45fd827f70799.
Discussion: https://postgr.es/m/CA%2BhUKGJmcqAE3MZeDCLLXa62cWM0AJbKmp2JrJYaJ86bz36LFA%40mail.gmail.com
M src/backend/executor/nodeHash.c
M src/backend/executor/nodeHashjoin.c
M src/include/executor/hashjoin.h
Fix race in Parallel Hash Join batch cleanup.
commit : 8fa2478b407ef867d501fafcdea45fd827f70799
author : Thomas Munro <[email protected]>
date : Wed, 17 Mar 2021 17:46:39 +1300
committer: Thomas Munro <[email protected]>
date : Wed, 17 Mar 2021 17:46:39 +1300
With very unlucky timing and parallel_leader_participation off, PHJ
could attempt to access per-batch state just as it was being freed.
There was code intended to prevent that by checking for a cleared
pointer, but it was buggy.
Fix, by introducing an extra barrier phase. The new phase
PHJ_BUILD_RUNNING means that it's safe to access the per-batch state to
find a batch to help with, and PHJ_BUILD_DONE means that it is too late.
The last to detach will free the array of per-batch state as before, but
now it will also atomically advance the phase at the same time, so that
late attachers can avoid the hazard, without the data race. This
mirrors the way per-batch hash tables are freed (see phases
PHJ_BATCH_PROBING and PHJ_BATCH_DONE).
Revealed by a one-off build farm failure, where BarrierAttach() failed a
sanity check assertion, because the memory had been clobbered by
dsa_free().
Back-patch to 11, where the code arrived.
Reported-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/20200929061142.GA29096%40paquier.xyz
M src/backend/executor/nodeHash.c
M src/backend/executor/nodeHashjoin.c
M src/include/executor/hashjoin.h
Avoid corner-case memory leak in SSL parameter processing.
commit : 6e34755560aa1bf241b498968f7ac26ea11ec15c
author : Tom Lane <[email protected]>
date : Tue, 16 Mar 2021 16:02:49 -0400
committer: Tom Lane <[email protected]>
date : Tue, 16 Mar 2021 16:02:49 -0400
After reading the root cert list from the ssl_ca_file, immediately
install it as client CA list of the new SSL context. That gives the
SSL context ownership of the list, so that SSL_CTX_free will free it.
This avoids a permanent memory leak if we fail further down in
be_tls_init(), which could happen if bogus CRL data is offered.
The leak could only amount to something if the CRL parameters get
broken after server start (else we'd just quit) and then the server
is SIGHUP'd many times without fixing the CRL data. That's rather
unlikely perhaps, but it seems worth fixing, if only because the
code is clearer this way.
While we're here, add some comments about the memory management
aspects of this logic.
Noted by Jelte Fennema and independently by Andres Freund.
Back-patch to v10; before commit de41869b6 it doesn't matter,
since we'd not re-execute this code during SIGHUP.
Discussion: https://postgr.es/m/[email protected]
M src/backend/libpq/be-secure-openssl.c
Fix race condition in psql \e's detection of file modification.
commit : 60e5c2b143a4bba698992d65cbab363550d5c863
author : Tom Lane <[email protected]>
date : Fri, 12 Mar 2021 12:20:15 -0500
committer: Tom Lane <[email protected]>
date : Fri, 12 Mar 2021 12:20:15 -0500
psql's editing commands decide whether the user has edited the file
by checking for change of modification timestamp. This is probably
fine for a pre-existing file, but with a temporary file that is
created within the command, it's possible for a fast typist to
save-and-exit in less than the one-second granularity of stat(2)
timestamps. On Windows FAT filesystems the granularity is even
worse, 2 seconds, making the race a bit easier to hit.
To fix, try to set the temp file's mod time to be two seconds ago.
It's unlikely this would fail, but then again the race condition
itself is unlikely, so just ignore any error.
Also, we might as well check the file size as well as its mod time.
While this is a difficult bug to hit, it still seems worth
back-patching, to ensure that users' edits aren't lost.
Laurenz Albe, per gripe from Jacob Champion; based on fix suggestions
from Jacob and myself
Discussion: https://postgr.es/m/[email protected]
M src/bin/psql/command.c
Forbid marking an identity column as nullable.
commit : e7f7950f6741a799bdf1dc3d2dbcb85e1b0a3c8c
author : Tom Lane <[email protected]>
date : Fri, 12 Mar 2021 11:08:42 -0500
committer: Tom Lane <[email protected]>
date : Fri, 12 Mar 2021 11:08:42 -0500
GENERATED ALWAYS AS IDENTITY implies NOT NULL, but the code failed
to complain if you overrode that with "GENERATED ALWAYS AS IDENTITY
NULL". One might think the old behavior was a feature, but it was
inconsistent because the outcome varied depending on the order of
the clauses, so it seems to have been just an oversight.
Per bug #16913 from Pavel Boev. Back-patch to v10 where identity
columns were introduced.
Vik Fearing (minor tweaks by me)
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/create_table.sgml
M src/backend/parser/parse_utilcmd.c
M src/test/regress/expected/identity.out
M src/test/regress/sql/identity.sql
Restore vacuum_cleanup_index_scale_factor coverage.
commit : ce54c024d9bf3022690dc84a17f1207aceec430a
author : Peter Geoghegan <[email protected]>
date : Thu, 11 Mar 2021 12:52:37 -0800
committer: Peter Geoghegan <[email protected]>
date : Thu, 11 Mar 2021 12:52:37 -0800
Revert two recent commits that had btree_index.sql drop regression test
indexes rather than leave them behind for pg_dump testing.
This is intended to restore pg_upgrade coverage of indexes with the
vacuum_cleanup_index_scale_factor storage parameter set on buildfarm
member crake.
Backpatch: 11-12 only
M src/test/regress/expected/btree_index.out
M src/test/regress/sql/btree_index.sql
Re-simplify management of inStart in pqParseInput3's subroutines.
commit : 56defbdd0f4e152545c50619385902ed060dca61
author : Tom Lane <[email protected]>
date : Thu, 11 Mar 2021 14:43:45 -0500
committer: Tom Lane <[email protected]>
date : Thu, 11 Mar 2021 14:43:45 -0500
Commit 92785dac2 copied some logic related to advancement of inStart
from pqParseInput3 into getRowDescriptions and getAnotherTuple,
because it wanted to allow user-defined row processor callbacks to
potentially longjmp out of the library, and inStart would have to be
updated before that happened to avoid an infinite loop. We later
decided that that API was impossibly fragile and reverted it, but
we didn't undo all of the related code changes, and this bit of
messiness survived. Undo it now so that there's just one place in
pqParseInput3's processing where inStart is advanced; this will
simplify addition of better tracing support.
getParamDescriptions had grown similar processing somewhere along
the way (not in 92785dac2; I didn't track down just when), but it's
actually buggy because its handling of corrupt-message cases seems to
have been copied from the v2 logic where we lacked a known message
length. The cases where we "goto not_enough_data" should not simply
return EOF, because then we won't consume the message, potentially
creating an infinite loop. That situation now represents a
definitively corrupt message, and we should report it as such.
Although no field reports of getParamDescriptions getting stuck in
a loop have been seen, it seems appropriate to back-patch that fix.
I chose to back-patch all of this to keep the logic looking more alike
in supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/libpq/fe-protocol3.c
Drop other index behind pg_upgrade test issue.
commit : 1cc33ab95ccea0e1e36651d57ca1c8088f9994c2
author : Peter Geoghegan <[email protected]>
date : Wed, 10 Mar 2021 23:32:58 -0800
committer: Peter Geoghegan <[email protected]>
date : Wed, 10 Mar 2021 23:32:58 -0800
Fix the test failure by dropping the index in question. Missed by
commit 57ae7885.
Per buildfarm member crake.
Backpatch: 11-12 only
M src/test/regress/expected/btree_index.out
M src/test/regress/sql/btree_index.sql
Drop index behind pg_upgrade test issue.
commit : 57ae7885cfe7a6301e1fd4b59c2e525ecc35cd55
author : Peter Geoghegan <[email protected]>
date : Wed, 10 Mar 2021 19:00:48 -0800
committer: Peter Geoghegan <[email protected]>
date : Wed, 10 Mar 2021 19:00:48 -0800
The vacuum_cleanup_index_scale_factor storage parameter was set in a
btree index that was previously left behind in the regression test
database. As a result, the index gets tested within pg_dump and
pg_restore tests, as well as pg_upgrade testing. This won't work when
upgrading to Postgres 14, though, because the storage parameter was
removed on that version by commit 9f3665fb.
Fix the test failure by dropping the index in question.
Per buildfarm member crake.
Discussion: https://postgr.es/m/CAH2-WzmeXYBWdhF7BMhNjhq9exsk=E1ohqBFAwzPdXJZ1XDMUA@mail.gmail.com
Backpatch: 11-12 only
M src/test/regress/expected/btree_index.out
M src/test/regress/sql/btree_index.sql
tutorial: land height is "elevation", not "altitude"
commit : 5645a6af70adaaaa485b8568bad9bc7fc130d474
author : Bruce Momjian <[email protected]>
date : Wed, 10 Mar 2021 20:25:18 -0500
committer: Bruce Momjian <[email protected]>
date : Wed, 10 Mar 2021 20:25:18 -0500
This is a follow-on patch to 92c12e46d5. In that patch, we renamed
"altitude" to "elevation" in the docs, based on these details:
https://mapscaping.com/blogs/geo-candy/what-is-the-difference-between-elevation-relief-and-altitude
This renames the tutorial SQL files to match the documentation.
Reported-by: [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M src/tutorial/advanced.source
Doc: improve introductory information about procedures.
commit : 74207b8fc5a03a902171460aa42f7d816f2c6597
author : Tom Lane <[email protected]>
date : Wed, 10 Mar 2021 11:33:50 -0500
committer: Tom Lane <[email protected]>
date : Wed, 10 Mar 2021 11:33:50 -0500
Clarify the discussion in "User-Defined Procedures", by laying out
the key differences between functions and procedures in a bulleted
list. Notably, this avoids burying the lede about procedures being
able to do transaction control. Make the back-link in the CREATE
FUNCTION reference page more prominent, and add one in CREATE
PROCEDURE.
Per gripe from Guyren Howe. Thanks to David Johnston for discussion.
Discussion: https://postgr.es/m/BYAPR03MB4903C53A8BB7EFF5EA289674A6949@BYAPR03MB4903.namprd03.prod.outlook.com
M doc/src/sgml/ref/create_function.sgml
M doc/src/sgml/ref/create_procedure.sgml
M doc/src/sgml/xfunc.sgml
Validate the OID argument of pg_import_system_collations().
commit : 8fff8a87493a238b45ecf6635baf334c4051b9df
author : Tom Lane <[email protected]>
date : Mon, 8 Mar 2021 18:21:51 -0500
committer: Tom Lane <[email protected]>
date : Mon, 8 Mar 2021 18:21:51 -0500
"SELECT pg_import_system_collations(0)" caused an assertion failure.
With a random nonzero argument --- or indeed with zero, in non-assert
builds --- it would happily make pg_collation entries with garbage
values of collnamespace. These are harmless as far as I can tell
(unless maybe the OID happens to become used for a schema, later on?).
In any case this isn't a security issue, since the function is
superuser-only. But it seems like a gotcha for unwary DBAs, so let's
add a check that the given OID belongs to some schema.
Back-patch to v10 where this function was introduced.
M src/backend/commands/collationcmds.c
Clarify the usage of max_replication_slots on the subscriber side.
commit : c267ca682803f8ca233076d216fba18b635238a6
author : Amit Kapila <[email protected]>
date : Wed, 3 Mar 2021 10:30:27 +0530
committer: Amit Kapila <[email protected]>
date : Wed, 3 Mar 2021 10:30:27 +0530
It was not clear in the docs that the max_replication_slots is also used
to track replication origins on the subscriber side.
Author: Paul Martinez
Reviewed-by: Amit Kapila
Backpatch-through: 10 where logical replication was introduced
Discussion: https://postgr.es/m/CACqFVBZgwCN_pHnW6dMNCrOS7tiHCw6Retf_=U2Vvj3aUSeATw@mail.gmail.com
M doc/src/sgml/config.sgml
M doc/src/sgml/logical-replication.sgml
Use native path separators to pg_ctl in initdb
commit : f927767919e8d7079043d637d2177b554126ad6c
author : Alvaro Herrera <[email protected]>
date : Tue, 2 Mar 2021 15:39:34 -0300
committer: Alvaro Herrera <[email protected]>
date : Tue, 2 Mar 2021 15:39:34 -0300
On Windows, CMD.EXE allegedly does not run a command that uses forward slashes,
so let's convert the path to use backslashes instead.
Backpatch to 10.
Author: Nitin Jadhav <[email protected]>
Reviewed-by: Juan José Santamaría Flecha <[email protected]>
Discussion: https://postgr.es/m/CAMm1aWaNDuaPYFYMAqDeJrZmPtNvLcJRS++CcZWY8LT6KcoBZw@mail.gmail.com
M src/bin/initdb/initdb.c
Fix duplicated test case in TAP tests of reindexdb
commit : 0f1b0c0b60ef7b56bbccacd4307fdda8afa1a59b
author : Michael Paquier <[email protected]>
date : Tue, 2 Mar 2021 13:19:11 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 2 Mar 2021 13:19:11 +0900
The same test for REINDEX (VERBOSE) was done twice, while it is clear
that the second test should use --concurrently. Issue introduced in
5dc92b8, for what looks like a copy-paste mistake.
Reviewed-by: Mark Dilger
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M src/bin/scripts/t/090_reindexdb.pl
Fix use-after-free bug with AfterTriggersTableData.storeslot
commit : 262eb990c72097bd804e5c747fe38bf9b3a1ded9
author : Alvaro Herrera <[email protected]>
date : Sat, 27 Feb 2021 18:09:15 -0300
committer: Alvaro Herrera <[email protected]>
date : Sat, 27 Feb 2021 18:09:15 -0300
AfterTriggerSaveEvent() wrongly allocates the slot in execution-span
memory context, whereas the correct thing is to allocate it in
a transaction-span context, because that's where the enclosing
AfterTriggersTableData instance belongs into.
Backpatch to 12 (the test back to 11, where it works well with no code
changes, and it's good to have to confirm that the case was previously
well supported); this bug seems introduced by commit ff11e7f4b9ae.
Reported-by: Bertrand Drouvot <[email protected]>
Author: Amit Langote <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Doc: further clarify libpq's description of connection string URIs.
commit : fb1e218cb07e9b78a26d52d1c7fc03f5ce8691eb
author : Tom Lane <[email protected]>
date : Fri, 26 Feb 2021 15:24:01 -0500
committer: Tom Lane <[email protected]>
date : Fri, 26 Feb 2021 15:24:01 -0500
Break the synopsis into named parts to make it less confusing.
Make more than zero effort at applying SGML markup. Do a bit
of copy-editing of nearby text.
The synopsis revision is by Alvaro Herrera and Paul Förster,
the rest is my fault. Back-patch to v10 where multi-host
connection strings appeared.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/libpq.sgml
doc: Mention PGDATABASE as supported by pgbench
commit : 9e9b5c05010d25e16e04c8c282a52626650ae233
author : Michael Paquier <[email protected]>
date : Thu, 25 Feb 2021 16:07:08 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 25 Feb 2021 16:07:08 +0900
PGHOST, PGPORT and PGUSER were already mentioned, but not PGDATABASE.
Like 5aaa584, backpatch down to 12.
Reported-by: Christophe Courtois
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M doc/src/sgml/ref/pgbench.sgml
Fix some typos, grammar and style in docs and comments
commit : 3b2af88788e1e136bcde78b74ff7387b0c58488a
author : Michael Paquier <[email protected]>
date : Wed, 24 Feb 2021 16:14:00 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 24 Feb 2021 16:14:00 +0900
The portions fixing the documentation are backpatched where needed.
Author: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
backpatch-through: 9.6
M doc/src/sgml/charset.sgml
M doc/src/sgml/pageinspect.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/ref/create_type.sgml
M doc/src/sgml/ref/drop_index.sgml
M doc/src/sgml/rules.sgml
Reinstate HEAP_XMAX_LOCK_ONLY|HEAP_KEYS_UPDATED as allowed
commit : 2796ae2ad25330e80e97e823aa72091a9374d87d
author : Alvaro Herrera <[email protected]>
date : Tue, 23 Feb 2021 17:30:21 -0300
committer: Alvaro Herrera <[email protected]>
date : Tue, 23 Feb 2021 17:30:21 -0300
Commit 866e24d47db1 added an assert that HEAP_XMAX_LOCK_ONLY and
HEAP_KEYS_UPDATED cannot appear together, on the faulty assumption that
the latter necessarily referred to an update and not a tuple lock; but
that's wrong, because SELECT FOR UPDATE can use precisely that
combination, as evidenced by the amcheck test case added here.
Remove the Assert(), and also patch amcheck's verify_heapam.c to not
complain if the combination is found. Also, out of overabundance of
caution, update (across all branches) README.tuplock to be more explicit
about this.
Author: Julien Rouhaud <[email protected]>
Reviewed-by: Mahendra Singh Thalor <[email protected]>
Reviewed-by: Dilip Kumar <[email protected]>
Discussion: https://postgr.es/m/20210124061758.GA11756@nol
M src/backend/access/heap/README.tuplock
Fix psql's ON_ERROR_ROLLBACK so that it handles COMMIT AND CHAIN.
commit : 67b3ee292935352b4b12b7a1bce17c64f85ce32e
author : Fujii Masao <[email protected]>
date : Fri, 19 Feb 2021 22:01:25 +0900
committer: Fujii Masao <[email protected]>
date : Fri, 19 Feb 2021 22:01:25 +0900
When ON_ERROR_ROLLBACK is enabled, psql releases a temporary savepoint
if it's idle in a valid transaction block after executing a query. But psql
doesn't do that after RELEASE or ROLLBACK is executed because a temporary
savepoint has already been destroyed in that case.
This commit changes psql's ON_ERROR_ROLLBACK so that it doesn't release
a temporary savepoint also when COMMIT AND CHAIN is executed. A temporary
savepoint doesn't need to be released in that case because
COMMIT AND CHAIN also destroys any savepoints defined within the transaction
to commit. Otherwise psql tries to release the savepoint that
COMMIT AND CHAIN has already destroyed and cause an error
"ERROR: savepoint "pg_psql_temporary_savepoint" does not exist".
Back-patch to v12 where transaction chaining was added.
Reported-by: Arthur Nascimento
Author: Arthur Nascimento
Reviewed-by: Fujii Masao, Vik Fearing
Discussion: https://postgr.es/m/[email protected]
M src/bin/psql/common.c
Fix bug in COMMIT AND CHAIN command.
commit : fadcc4e81bd99e6032ae042cae53be0c6eea7580
author : Fujii Masao <[email protected]>
date : Fri, 19 Feb 2021 21:57:52 +0900
committer: Fujii Masao <[email protected]>
date : Fri, 19 Feb 2021 21:57:52 +0900
This commit fixes COMMIT AND CHAIN command so that it starts new transaction
immediately even if savepoints are defined within the transaction to commit.
Previously COMMIT AND CHAIN command did not in that case because
commit 280a408b48 forgot to make CommitTransactionCommand() handle
a transaction chaining when the transaction state was TBLOCK_SUBCOMMIT.
Also this commit adds the regression test for COMMIT AND CHAIN command
when savepoints are defined.
Back-patch to v12 where transaction chaining was added.
Reported-by: Arthur Nascimento
Author: Fujii Masao
Reviewed-by: Arthur Nascimento, Vik Fearing
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/xact.c
M src/test/regress/expected/transactions.out
M src/test/regress/sql/transactions.sql
Fix another ancient bug in parsing of BRE-mode regular expressions.
commit : e7cddb5f29171a536233acecb7ac9b9c5e1b4c77
author : Tom Lane <[email protected]>
date : Thu, 18 Feb 2021 22:38:55 -0500
committer: Tom Lane <[email protected]>
date : Thu, 18 Feb 2021 22:38:55 -0500
While poking at the regex code, I happened to notice that the bug
squashed in commit afcc8772e had a sibling: next() failed to return
a specific value associated with the '}' token for a "\{m,n\}"
quantifier when parsing in basic RE mode. Again, this could result
in treating the quantifier as non-greedy, which it never should be in
basic mode. For that to happen, the last character before "\}" that
sets "nextvalue" would have to set it to zero, or it'd have to have
accidentally been zero from the start. The failure can be provoked
repeatably with, for example, a bound ending in digit "0".
Like the previous patch, back-patch all the way.
M src/backend/regex/regc_lex.c
Fix typo
commit : 6a31b48ec88ae506c6f115948c86f61abb89a89a
author : Magnus Hagander <[email protected]>
date : Wed, 17 Feb 2021 13:53:26 +0100
committer: Magnus Hagander <[email protected]>
date : Wed, 17 Feb 2021 13:53:26 +0100
Author: Daniel Gustafsson <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/create_table.sgml
Make ExecGetInsertedCols() and friends more robust and improve comments.
commit : 2b81444a88cc499f5d3608c5943e9a6e4b489070
author : Heikki Linnakangas <[email protected]>
date : Mon, 15 Feb 2021 09:28:08 +0200
committer: Heikki Linnakangas <[email protected]>
date : Mon, 15 Feb 2021 09:28:08 +0200
If ExecGetInsertedCols(), ExecGetUpdatedCols() or ExecGetExtraUpdatedCols()
were called with a ResultRelInfo that's not in the range table and isn't a
partition routing target, the functions would dereference a NULL pointer,
relinfo->ri_RootResultRelInfo. Such ResultRelInfos are created when firing
RI triggers in tables that are not modified directly. None of the current
callers of these functions pass such relations, so this isn't a live bug,
but let's make them more robust.
Also update comment in ResultRelInfo; after commit 6214e2b228,
ri_RangeTableIndex is zero for ResultRelInfos created for partition tuple
routing.
Noted by Coverity. Backpatch down to v11, like commit 6214e2b228.
Reviewed-by: Tom Lane, Amit Langote
M src/backend/executor/execUtils.c
M src/include/nodes/execnodes.h
Default to wal_sync_method=fdatasync on FreeBSD.
commit : a27f3a7f4159c5afaf33932df16ca4fed6689c06
author : Thomas Munro <[email protected]>
date : Mon, 15 Feb 2021 15:43:39 +1300
committer: Thomas Munro <[email protected]>
date : Mon, 15 Feb 2021 15:43:39 +1300
FreeBSD 13 gained O_DSYNC, which would normally cause wal_sync_method to
choose open_datasync as its default value. That may not be a good
choice for all systems, and performs worse than fdatasync in some
scenarios. Let's preserve the existing default behavior for now.
Like commit 576477e73c4, which did the same for Linux, back-patch to all
supported releases.
Discussion: https://postgr.es/m/CA%2BhUKGLsAMXBQrCxCXoW-JsUYmdOL8ALYvaX%3DCrHqWxm-nWbGA%40mail.gmail.com
M doc/src/sgml/config.sgml
M src/backend/utils/misc/postgresql.conf.sample
M src/include/port/freebsd.h
Hold interrupts while running dsm_detach() callbacks.
commit : 840eda04ebc99ce211ffd11946a59ad43c42bfa6
author : Thomas Munro <[email protected]>
date : Mon, 15 Feb 2021 13:32:58 +1300
committer: Thomas Munro <[email protected]>
date : Mon, 15 Feb 2021 13:32:58 +1300
While cleaning up after a parallel query or parallel index creation that
created temporary files, we could be interrupted by a statement timeout.
The error handling path would then fail to clean up the files when it
ran dsm_detach() again, because the callback was already popped off the
list. Prevent this hazard by holding interrupts while the cleanup code
runs.
Thanks to Heikki Linnakangas for this suggestion, and also to Kyotaro
Horiguchi, Masahiko Sawada, Justin Pryzby and Tom Lane for discussion of
this and earlier ideas on how to fix the problem.
Back-patch to all supported releases.
Reported-by: Justin Pryzby <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/storage/ipc/dsm.c
pg_attribute_no_sanitize_alignment() macro
commit : c3dc311ffd6417b15a467c6ea53e642577e9f00e
author : Tom Lane <[email protected]>
date : Sat, 13 Feb 2021 17:49:08 -0500
committer: Tom Lane <[email protected]>
date : Sat, 13 Feb 2021 17:49:08 -0500
Modern gcc and clang compilers offer alignment sanitizers, which help to detect
pointer misalignment. However, our codebase already contains x86-specific
crc32 computation code, which uses unalignment access. Thankfully, those
compilers also support the attribute, which disables alignment sanitizers at
the function level. This commit adds pg_attribute_no_sanitize_alignment(),
which wraps this attribute, and applies it to pg_comp_crc32c_sse42() function.
Back-patch of commits 993bdb9f9 and ad2ad698a, to enable doing
alignment testing in all supported branches.
Discussion: https://postgr.es/m/CAPpHfdsne3%3DT%3DfMNU45PtxdhSL_J2PjLTeS8rwKnJzUR4YNd4w%40mail.gmail.com
Discussion: https://postgr.es/m/475514.1612745257%40sss.pgh.pa.us
Author: Alexander Korotkov, revised by Tom Lane
Reviewed-by: Tom Lane
M src/include/c.h
M src/port/pg_crc32c_sse42.c
Avoid divide-by-zero in regex_selectivity() with long fixed prefix.
commit : 0347470b31c139aa4f1d366fbdb85f32b7f82ad0
author : Tom Lane <[email protected]>
date : Fri, 12 Feb 2021 16:26:47 -0500
committer: Tom Lane <[email protected]>
date : Fri, 12 Feb 2021 16:26:47 -0500
Given a regex pattern with a very long fixed prefix (approaching 500
characters), the result of pow(FIXED_CHAR_SEL, fixed_prefix_len) can
underflow to zero. Typically the preceding selectivity calculation
would have underflowed as well, so that we compute 0/0 and get NaN.
In released branches this leads to an assertion failure later on.
That doesn't happen in HEAD, for reasons I've not explored yet,
but it's surely still a bug.
To fix, just skip the division when the pow() result is zero, so
that we'll (most likely) return a zero selectivity estimate. In
the edge cases where "sel" didn't yet underflow, perhaps this
isn't desirable, but I'm not sure that the case is worth spending
a lot of effort on. The results of regex_selectivity_sub() are
barely worth the electrons they're written on anyway :-(
Per report from Alexander Lakhin. Back-patch to all supported versions.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/like_support.c
Fix ORDER BY clause in new regression test of REINDEX CONCURRENTLY
commit : 5b2945ec0a39959962072c39d1817d0fdf23d486
author : Michael Paquier <[email protected]>
date : Wed, 10 Feb 2021 16:59:04 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 10 Feb 2021 16:59:04 +0900
Oversight in bd12080.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Preserve pg_attribute.attstattarget across REINDEX CONCURRENTLY
commit : 85edb1f2615d48bdc2420b00c55286eef3a3244c
author : Michael Paquier <[email protected]>
date : Wed, 10 Feb 2021 13:09:12 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 10 Feb 2021 13:09:12 +0900
For an index, attstattarget can be updated using ALTER INDEX SET
STATISTICS. This data was lost on the new index after REINDEX
CONCURRENTLY.
The update of this field is done when the old and new indexes are
swapped to make the fix back-patchable. Another approach we could look
after in the long-term is to change index_create() to pass the wanted
values of attstattarget when creating the new relation, but, as this
would cause an ABI breakage this can be done only on HEAD.
Reported-by: Ronan Dunklau
Author: Michael Paquier
Reviewed-by: Ronan Dunklau, Tomas Vondra
Discussion: https://postgr.es/m/16628084.uLZWGnKmhe@laptop-ronand
Backpatch-through: 12
M src/backend/catalog/index.c
M src/backend/utils/cache/lsyscache.c
M src/include/utils/lsyscache.h
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql