Stamp 9.6.10.
commit : ca3489e768990e32096f0f24d46d5f0b8b70cff4
author : Tom Lane <[email protected]>
date : Mon, 6 Aug 2018 16:07:43 -0400
committer: Tom Lane <[email protected]>
date : Mon, 6 Aug 2018 16:07:43 -0400
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Translation updates
commit : d275672f7d9ad12b882687debeed549ab5ad0251
author : Peter Eisentraut <[email protected]>
date : Mon, 6 Aug 2018 19:44:29 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 6 Aug 2018 19:44:29 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 439efc0cb9779c62ae569c397267d7bc55c6ef4f
M src/backend/nls.mk
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/it.po
A src/backend/po/sv.po
A src/backend/po/tr.po
M src/bin/initdb/nls.mk
M src/bin/initdb/po/cs.po
M src/bin/initdb/po/sv.po
A src/bin/initdb/po/tr.po
M src/bin/pg_basebackup/nls.mk
A src/bin/pg_basebackup/po/cs.po
M src/bin/pg_basebackup/po/it.po
A src/bin/pg_basebackup/po/sv.po
A src/bin/pg_basebackup/po/tr.po
M src/bin/pg_config/po/cs.po
M src/bin/pg_config/po/sv.po
M src/bin/pg_controldata/nls.mk
M src/bin/pg_controldata/po/cs.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/sv.po
A src/bin/pg_controldata/po/tr.po
M src/bin/pg_ctl/nls.mk
M src/bin/pg_ctl/po/cs.po
M src/bin/pg_ctl/po/sv.po
A src/bin/pg_ctl/po/tr.po
M src/bin/pg_dump/nls.mk
M src/bin/pg_dump/po/cs.po
A src/bin/pg_dump/po/sv.po
A src/bin/pg_dump/po/tr.po
M src/bin/pg_resetxlog/nls.mk
M src/bin/pg_resetxlog/po/cs.po
M src/bin/pg_resetxlog/po/sv.po
A src/bin/pg_resetxlog/po/tr.po
M src/bin/pg_rewind/nls.mk
A src/bin/pg_rewind/po/cs.po
A src/bin/pg_rewind/po/sv.po
A src/bin/pg_rewind/po/tr.po
M src/bin/psql/nls.mk
M src/bin/psql/po/cs.po
M src/bin/psql/po/sv.po
A src/bin/psql/po/tr.po
M src/bin/scripts/nls.mk
M src/bin/scripts/po/cs.po
M src/bin/scripts/po/sv.po
A src/bin/scripts/po/tr.po
M src/interfaces/ecpg/ecpglib/nls.mk
M src/interfaces/ecpg/ecpglib/po/cs.po
A src/interfaces/ecpg/ecpglib/po/sv.po
M src/interfaces/ecpg/preproc/nls.mk
M src/interfaces/ecpg/preproc/po/cs.po
A src/interfaces/ecpg/preproc/po/sv.po
M src/interfaces/libpq/nls.mk
M src/interfaces/libpq/po/cs.po
A src/interfaces/libpq/po/sv.po
M src/interfaces/libpq/po/tr.po
M src/pl/plperl/po/cs.po
M src/pl/plperl/po/sv.po
M src/pl/plperl/po/tr.po
M src/pl/plpgsql/src/nls.mk
M src/pl/plpgsql/src/po/cs.po
A src/pl/plpgsql/src/po/sv.po
A src/pl/plpgsql/src/po/tr.po
M src/pl/plpython/nls.mk
M src/pl/plpython/po/cs.po
A src/pl/plpython/po/sv.po
A src/pl/plpython/po/tr.po
M src/pl/tcl/nls.mk
M src/pl/tcl/po/cs.po
A src/pl/tcl/po/sv.po
M src/pl/tcl/po/tr.po
Last-minute updates for release notes.
commit : 3fd77b1dccb8539d68a517711bfd29310ecc4c04
author : Tom Lane <[email protected]>
date : Mon, 6 Aug 2018 13:13:41 -0400
committer: Tom Lane <[email protected]>
date : Mon, 6 Aug 2018 13:13:41 -0400
Security: CVE-2018-10915, CVE-2018-10925
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
M doc/src/sgml/release-9.5.sgml
M doc/src/sgml/release-9.6.sgml
Fix failure to reset libpq's state fully between connection attempts.
commit : a8094d0fe73188e9ff05f210c11c4b251d1442f1
author : Tom Lane <[email protected]>
date : Mon, 6 Aug 2018 10:53:35 -0400
committer: Tom Lane <[email protected]>
date : Mon, 6 Aug 2018 10:53:35 -0400
The logic in PQconnectPoll() did not take care to ensure that all of
a PGconn's internal state variables were reset before trying a new
connection attempt. If we got far enough in the connection sequence
to have changed any of these variables, and then decided to try a new
server address or server name, the new connection might be completed
with some state that really only applied to the failed connection.
While this has assorted bad consequences, the only one that is clearly
a security issue is that password_needed didn't get reset, so that
if the first server asked for a password and the second didn't,
PQconnectionUsedPassword() would return an incorrect result. This
could be leveraged by unprivileged users of dblink or postgres_fdw
to allow them to use server-side login credentials that they should
not be able to use.
Other notable problems include the possibility of forcing a v2-protocol
connection to a server capable of supporting v3, or overriding
"sslmode=prefer" to cause a non-encrypted connection to a server that
would have accepted an encrypted one. Those are certainly bugs but
it's harder to paint them as security problems in themselves. However,
forcing a v2-protocol connection could result in libpq having a wrong
idea of the server's standard_conforming_strings setting, which opens
the door to SQL-injection attacks. The extent to which that's actually
a problem, given the prerequisite that the attacker needs control of
the client's connection parameters, is unclear.
These problems have existed for a long time, but became more easily
exploitable in v10, both because it introduced easy ways to force libpq
to abandon a connection attempt at a late stage and then try another one
(rather than just giving up), and because it provided an easy way to
specify multiple target hosts.
Fix by rearranging PQconnectPoll's state machine to provide centralized
places to reset state properly when moving to a new target host or when
dropping and retrying a connection to the same host.
Tom Lane, reviewed by Noah Misch. Our thanks to Andrew Krasichkov
for finding and reporting the problem.
Security: CVE-2018-10915
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/libpq-int.h
Adjust error message
commit : 5ba761929caa92167e8b6327cc1c21b6cac5e7cb
author : Peter Eisentraut <[email protected]>
date : Mon, 11 Jun 2018 17:19:11 -0400
committer: Peter Eisentraut <[email protected]>
date : Mon, 11 Jun 2018 17:19:11 -0400
Makes it look more similar to other ones, and avoids the need for
pluralization.
M src/common/controldata_utils.c
Release notes for 10.5, 9.6.10, 9.5.14, 9.4.19, 9.3.24.
commit : 637b3be527f2fef8246f60a82781cb9c661891d9
author : Tom Lane <[email protected]>
date : Sun, 5 Aug 2018 16:38:43 -0400
committer: Tom Lane <[email protected]>
date : Sun, 5 Aug 2018 16:38:43 -0400
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
M doc/src/sgml/release-9.5.sgml
M doc/src/sgml/release-9.6.sgml
Doc: fix incorrectly stated argument list for pgcrypto's hmac() function.
commit : 7171a60cf45cbef1960dc96adeabdff287c700bd
author : Tom Lane <[email protected]>
date : Sun, 5 Aug 2018 13:03:42 -0400
committer: Tom Lane <[email protected]>
date : Sun, 5 Aug 2018 13:03:42 -0400
The bytea variant takes (bytea, bytea, text).
Per unsigned report.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/pgcrypto.sgml
Fix INSERT ON CONFLICT UPDATE through a view that isn't just SELECT *.
commit : b484bffe7d0e527b3e8f853c80f600d66b247501
author : Tom Lane <[email protected]>
date : Sat, 4 Aug 2018 19:38:58 -0400
committer: Tom Lane <[email protected]>
date : Sat, 4 Aug 2018 19:38:58 -0400
When expanding an updatable view that is an INSERT's target, the rewriter
failed to rewrite Vars in the ON CONFLICT UPDATE clause. This accidentally
worked if the view was just "SELECT * FROM ...", as the transformation
would be a no-op in that case. With more complicated view targetlists,
this omission would often lead to "attribute ... has the wrong type" errors
or even crashes, as reported by Mario De Frutos Dieguez.
Fix by adding code to rewriteTargetView to fix up the data structure
correctly. The easiest way to update the exclRelTlist list is to rebuild
it from scratch looking at the new target relation, so factor the code
for that out of transformOnConflictClause to make it sharable.
In passing, avoid duplicate permissions checks against the EXCLUDED
pseudo-relation, and prevent useless view expansion of that relation's
dummy RTE. The latter is only known to happen (after this patch) in cases
where the query would fail later due to not having any INSTEAD OF triggers
for the view. But by exactly that token, it would create an unintended
and very poorly tested state of the query data structure, so it seems like
a good idea to prevent it from happening at all.
This has been broken since ON CONFLICT was introduced, so back-patch
to 9.5.
Dean Rasheed, based on an earlier patch by Amit Langote;
comment-kibitzing and back-patching by me
Discussion: https://postgr.es/m/CAFYwGJ0xfzy8jaK80hVN2eUWr6huce0RU8AgU04MGD00igqkTg@mail.gmail.com
M src/backend/parser/analyze.c
M src/backend/rewrite/rewriteHandler.c
M src/include/parser/analyze.h
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Reset properly errno before calling write()
commit : f5b4bb88120f8945ead702bec0e4eaf46542e8f3
author : Michael Paquier <[email protected]>
date : Sun, 5 Aug 2018 05:32:27 +0900
committer: Michael Paquier <[email protected]>
date : Sun, 5 Aug 2018 05:32:27 +0900
6cb3372 enforces errno to ENOSPC when less bytes than what is expected
have been written when it is unset, though it forgot to properly reset
errno before doing a system call to write(), causing errno to
potentially come from a previous system call.
Reported-by: Tom Lane
Author: Michael Paquier
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/heap/rewriteheap.c
M src/backend/access/transam/twophase.c
M src/backend/replication/logical/origin.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
M src/backend/replication/slot.c
M src/bin/pg_basebackup/receivelog.c
Add table relcache invalidation to index builds.
commit : 0a60a291c9a5b8ecdf44cbbfecc4504e3c21ef49
author : Peter Geoghegan <[email protected]>
date : Fri, 3 Aug 2018 14:44:44 -0700
committer: Peter Geoghegan <[email protected]>
date : Fri, 3 Aug 2018 14:44:44 -0700
It's necessary to make sure that owning tables have a relcache
invalidation prior to advancing the command counter to make
newly-entered catalog tuples for the index visible. inval.c must be
able to maintain the consistency of the local caches in the event of
transaction abort. There is usually only a problem when CREATE INDEX
transactions abort, since there is a generic invalidation once we reach
index_update_stats().
This bug is of long standing. Problems were made much more likely by
the addition of parallel CREATE INDEX (commit 9da0cc35284), but it is
strongly suspected that similar problems can be triggered without
involving plan_create_index_workers(). (plan_create_index_workers()
triggers a relcache build or rebuild, which previously only happened in
rare edge cases.)
Author: Peter Geoghegan
Reported-By: Luca Ferrari
Diagnosed-By: Andres Freund
Reviewed-By: Andres Freund
Discussion: https://postgr.es/m/CAKoxK+5fVodiCtMsXKV_1YAKXbzwSfp7DgDqUmcUAzeAhf=HEQ@mail.gmail.com
Backpatch: 9.3-
M src/backend/catalog/index.c
Fix pg_replication_slot example output
commit : 6faaf1b7303a62e092def1d3047707e9d42d1210
author : Alvaro Herrera <[email protected]>
date : Fri, 3 Aug 2018 16:34:59 -0400
committer: Alvaro Herrera <[email protected]>
date : Fri, 3 Aug 2018 16:34:59 -0400
The example output of pg_replication_slot is wrong. Correct it and make
the output stable by explicitly listing columns to output.
Author: Kyotaro Horiguchi <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/high-availability.sgml
Fix buffer usage stats for parallel nodes.
commit : 19df1702f5c5d5b7f1802e2a941b1a57ee47cc21
author : Amit Kapila <[email protected]>
date : Fri, 3 Aug 2018 11:43:01 +0530
committer: Amit Kapila <[email protected]>
date : Fri, 3 Aug 2018 11:43:01 +0530
The buffer usage stats is accounted only for the execution phase of the
node. For Gather and Gather Merge nodes, such stats are accumulated at
the time of shutdown of workers which is done after execution of node due
to which we missed to account them for such nodes. Fix it by treating
nodes as running while we shut down them.
We can also miss accounting for a Limit node when Gather or Gather Merge
is beneath it, because it can finish the execution before shutting down
such nodes. So we allow a Limit node to shut down the resources before it
completes the execution.
In the passing fix the gather node code to allow workers to shut down as
soon as we find that all the tuples from the workers have been retrieved.
The original code use to do that, but is accidently removed by commit
01edb5c7fc.
Reported-by: Adrien Nayrat
Author: Amit Kapila and Robert Haas
Reviewed-by: Robert Haas and Andres Freund
Backpatch-through: 9.6 where this code was introduced
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/execProcnode.c
M src/backend/executor/nodeLimit.c
Match the buffer usage tracking for leader and worker backends.
commit : 7124c93fb54fdd3bcf98e29392fc66ddb81f5343
author : Amit Kapila <[email protected]>
date : Fri, 3 Aug 2018 10:07:56 +0530
committer: Amit Kapila <[email protected]>
date : Fri, 3 Aug 2018 10:07:56 +0530
In the leader backend, we don't track the buffer usage for ExecutorStart
phase whereas in worker backend we track it for ExecutorStart phase as
well. This leads to different value for buffer usage stats for the
parallel and non-parallel query. Change the code so that worker backend
also starts tracking buffer usage after ExecutorStart.
Author: Amit Kapila and Robert Haas
Reviewed-by: Robert Haas and Andres Freund
Backpatch-through: 9.6 where this code was introduced
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/execParallel.c
pg_upgrade: fix --check for live source server checks
commit : 764e21db0e2eb384785f94bc0087229318250f9e
author : Bruce Momjian <[email protected]>
date : Tue, 31 Jul 2018 18:10:06 -0400
committer: Bruce Momjian <[email protected]>
date : Tue, 31 Jul 2018 18:10:06 -0400
Fix for commit 244142d32afd02e7408a2ef1f249b00393983822.
Backpatch-through: 9.3
M src/bin/pg_upgrade/controldata.c
Further fixes for quoted-list GUC values in pg_dump and ruleutils.c.
commit : 6680d19a80814190b37c1fad7a425a4694bccc0e
author : Tom Lane <[email protected]>
date : Tue, 31 Jul 2018 13:00:08 -0400
committer: Tom Lane <[email protected]>
date : Tue, 31 Jul 2018 13:00:08 -0400
Commits 742869946 et al turn out to be a couple bricks shy of a load.
We were dumping the stored values of GUC_LIST_QUOTE variables as they
appear in proconfig or setconfig catalog columns. However, although that
quoting rule looks a lot like SQL-identifier double quotes, there are two
critical differences: empty strings ("") are legal, and depending on which
variable you're considering, values longer than NAMEDATALEN might be valid
too. So the current technique fails altogether on empty-string list
entries (as reported by Steven Winfield in bug #15248) and it also risks
truncating file pathnames during dump/reload of GUC values that are lists
of pathnames.
To fix, split the stored value without any downcasing or truncation,
and then emit each element as a SQL string literal.
This is a tad annoying, because we now have three copies of the
comma-separated-string splitting logic in varlena.c as well as a fourth
one in dumputils.c. (Not to mention the randomly-different-from-those
splitting logic in libpq...) I looked at unifying these, but it would
be rather a mess unless we're willing to tweak the API definitions of
SplitIdentifierString, SplitDirectoriesString, or both. That might be
worth doing in future; but it seems pretty unsafe for a back-patched
bug fix, so for now accept the duplication.
Back-patch to all supported branches, as the previous fix was.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/ruleutils.c
M src/backend/utils/adt/varlena.c
M src/bin/pg_dump/dumputils.c
M src/bin/pg_dump/dumputils.h
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dumpall.c
M src/include/utils/builtins.h
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql
Fix pg_dump's failure to dump REPLICA IDENTITY for constraint indexes.
commit : 8c7f64b0ed32b8b7d62055efc153ddd17b4a8334
author : Tom Lane <[email protected]>
date : Mon, 30 Jul 2018 12:35:49 -0400
committer: Tom Lane <[email protected]>
date : Mon, 30 Jul 2018 12:35:49 -0400
pg_dump knew about printing ALTER TABLE ... REPLICA IDENTITY USING INDEX
for indexes declared as indexes, but it failed to print that for indexes
declared as unique or primary-key constraints. Per report from Achilleas
Mantzios.
This has been broken since the feature was introduced, AFAICS.
Back-patch to 9.4.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_dump/pg_dump.c
Doc: fix oversimplified example for CREATE POLICY.
commit : 9f508a9d70eedfd668b9377df298ba7e8e465596
author : Tom Lane <[email protected]>
date : Mon, 30 Jul 2018 11:54:41 -0400
committer: Tom Lane <[email protected]>
date : Mon, 30 Jul 2018 11:54:41 -0400
As written, this policy constrained only the post-image not the pre-image
of rows, meaning that users could delete other users' rows or take
ownership of such rows, contrary to what the docs claimed would happen.
We need two separate policies to achieve the documented effect.
While at it, try to explain what's happening a bit more fully.
Per report from Олег Самойлов. Back-patch to 9.5 where this was added.
Thanks to Stephen Frost for off-list discussion.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ddl.sgml
Fix earthdistance test suite function name typo.
commit : 9abc6565cd75cd5bd64b73da140469040429ce53
author : Noah Misch <[email protected]>
date : Sun, 29 Jul 2018 12:02:07 -0700
committer: Noah Misch <[email protected]>
date : Sun, 29 Jul 2018 12:02:07 -0700
Affected test queries have been testing the wrong thing since their
introduction in commit 4c1383efd132e4f532213c8a8cc63a455f55e344.
Back-patch to 9.3 (all supported versions).
M contrib/earthdistance/expected/earthdistance.out
M contrib/earthdistance/sql/earthdistance.sql
Document security implications of qualified names.
commit : 5eecc1cafdbddb21def03e4dd52eb8acf66b6efd
author : Noah Misch <[email protected]>
date : Sat, 28 Jul 2018 20:08:01 -0700
committer: Noah Misch <[email protected]>
date : Sat, 28 Jul 2018 20:08:01 -0700
Commit 5770172cb0c9df9e6ce27c507b449557e5b45124 documented secure schema
usage, and that advice suffices for using unqualified names securely.
Document, in typeconv-func primarily, the additional issues that arise
with qualified names. Back-patch to 9.3 (all supported versions).
Reviewed by Jonathan S. Katz.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_function.sgml
M doc/src/sgml/syntax.sgml
M doc/src/sgml/typeconv.sgml
M doc/src/sgml/xfunc.sgml
M src/backend/utils/adt/ruleutils.c
pgtest: run clean, build, and check stages separately
commit : 03131abe9b24a9806987f356da53a7a2440f3259
author : Bruce Momjian <[email protected]>
date : Sat, 28 Jul 2018 15:34:06 -0400
committer: Bruce Momjian <[email protected]>
date : Sat, 28 Jul 2018 15:34:06 -0400
This allows for cleaner error reporting.
Backpatch-through: 9.5
M src/tools/pgtest
pg_upgrade: check for clean server shutdowns
commit : a326ca75b3296747bd70d62fa550b6fe004ecd92
author : Bruce Momjian <[email protected]>
date : Sat, 28 Jul 2018 15:01:55 -0400
committer: Bruce Momjian <[email protected]>
date : Sat, 28 Jul 2018 15:01:55 -0400
Previously pg_upgrade checked for the pid file and started/stopped the
server to force a clean shutdown. However, "pg_ctl -m immediate"
removes the pid file but doesn't do a clean shutdown, so check
pg_controldata for a clean shutdown too.
Diagnosed-by: Vimalraj A
Discussion: https://postgr.es/m/CAFKBAK5e4Q-oTUuPPJ56EU_d2Rzodq6GWKS3ncAk3xo7hAsOZg@mail.gmail.com
Backpatch-through: 9.3
M src/bin/pg_upgrade/controldata.c
M src/bin/pg_upgrade/pg_upgrade.c
pgtest: grab possible warnings from install.log
commit : 5f2c5890e92c68163cb36b8551d45244d3280af9
author : Bruce Momjian <[email protected]>
date : Sat, 28 Jul 2018 11:35:52 -0400
committer: Bruce Momjian <[email protected]>
date : Sat, 28 Jul 2018 11:35:52 -0400
Since PG 9.5, 'make check' records the build output in install.log, so
look in there for warnings too.
Backpatch-through: 9.5
M src/tools/pgtest
doc: Fix reference to "decoder" to instead be the correct "output plugin".
commit : 2217fd9e97f0708972694e45c5d1f68bdf65a63b
author : Andres Freund <[email protected]>
date : Tue, 24 Jul 2018 10:51:17 -0700
committer: Andres Freund <[email protected]>
date : Tue, 24 Jul 2018 10:51:17 -0700
Author: Jonathan Katz
Discussion: https://postgr.es/m/[email protected]
Backpatch: 9.4-, where logical decoding was added
M doc/src/sgml/test-decoding.sgml
Further portability hacking in pg_upgrade's test script.
commit : 2cc81f95e698b9da07a98cfb63257f2ae635416a
author : Tom Lane <[email protected]>
date : Sat, 21 Jul 2018 15:40:51 -0400
committer: Tom Lane <[email protected]>
date : Sat, 21 Jul 2018 15:40:51 -0400
I blew the dust off a Bourne shell (file date 1996, yea verily) and
tried to run test.sh with it. It mostly worked, but I found that the
temp-directory creation code introduced by commit be76a6d39 was not
compatible, for a couple of reasons: this shell thinks "set -e" should
force an exit if a command within backticks fails, and it also thinks code
within braces should be executed by a sub-shell, meaning that variable
settings don't propagate back up to the parent shell. In view of Victor
Wagner's report that Solaris is still using pre-POSIX shells, seems like
we oughta make this case work. It's not like the code is any less
idiomatic this way; the prior coding technique appeared nowhere else.
(There is a remaining bash-ism here, which is that $RANDOM doesn't do
what the code hopes in non-bash shells. But the use of $$ elsewhere in
that path should be enough to ensure uniqueness and some amount of
randomness, so I think it's okay as-is.)
Back-patch to all supported branches, as the previous commit was.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_upgrade/test.sh
Fix handling of empty uncompressed posting list pages in GIN
commit : 44b550e0d9a5b3e4aba0211e7654b70e4f78b079
author : Alexander Korotkov <[email protected]>
date : Thu, 19 Jul 2018 21:04:17 +0300
committer: Alexander Korotkov <[email protected]>
date : Thu, 19 Jul 2018 21:04:17 +0300
PostgreSQL 9.4 introduces posting list compression in GIN. This feature
supports online upgrade, so that after pg_upgrade uncompressed posting
lists are compressed on-the-fly. Underlying code appears to always
expect at least one item on uncompressed posting list page. But there
could be completely empty pages, because VACUUM never deletes leftmost
and rightmost pages from posting trees. This commit fixes that.
Reported-by: Sivasubramanian Ramasubramanian
Discussion: https://postgr.es/m/1531867212836.63354%40amazon.com
Author: Sivasubramanian Ramasubramanian, Alexander Korotkov
Backpatch-through: 9.4
M src/backend/access/gin/gindatapage.c
M src/backend/access/gin/ginxlog.c
Rephrase a few comments for clarity.
commit : 8b1d2685b82fd0ab09c2ba36081e53248c3b09cb
author : Heikki Linnakangas <[email protected]>
date : Thu, 19 Jul 2018 16:08:09 +0300
committer: Heikki Linnakangas <[email protected]>
date : Thu, 19 Jul 2018 16:08:09 +0300
I was confused by what "intended to be parallel serially" meant, until
Robert Haas and David G. Johnston explained it. Rephrase the comment to
make it more clear, using David's suggested wording.
Discussion: https://www.postgresql.org/message-id/1fec9022-41e8-e484-70ce-2179b08c2092%40iki.fi
M src/backend/executor/nodeSeqscan.c
Fix print of Path nodes when using OPTIMIZER_DEBUG
commit : 164ed1532f78574a904b4bd080c28105a45e2765
author : Michael Paquier <[email protected]>
date : Thu, 19 Jul 2018 09:55:25 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 19 Jul 2018 09:55:25 +0900
GatherMergePath (introduced in 10) and CustomPath (introduced in 9.5)
have gone missing. The order of the Path nodes was inconsistent with
what is listed in nodes.h, so make the order consistent at the same time
to ease future checks and additions.
Author: Sawada Masahiko
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CAD21AoBQMLoc=ohH-oocuAPsELrmk8_EsRJjOyR8FQLZkbE0wA@mail.gmail.com
M src/backend/optimizer/path/allpaths.c
Fix misc typos, mostly in comments.
commit : 75459bc427d1598d72f9663ffa0fb910844d54a9
author : Heikki Linnakangas <[email protected]>
date : Mon, 9 Jul 2018 16:10:44 +0300
committer: Heikki Linnakangas <[email protected]>
date : Mon, 9 Jul 2018 16:10:44 +0300
A collection of typos I happened to spot while reading code, as well as
grepping for common mistakes.
Backpatch to all supported versions, as applicable, to avoid conflicts
when backporting other commits in the future.
M contrib/bloom/blscan.c
M src/backend/access/transam/multixact.c
M src/backend/commands/cluster.c
M src/backend/executor/nodeModifyTable.c
M src/backend/replication/logical/origin.c
M src/bin/initdb/t/001_initdb.pl
M src/bin/pg_upgrade/tablespace.c
M src/interfaces/ecpg/ecpglib/execute.c
M src/pl/tcl/pltcl.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/expected/rules.out
M src/test/regress/sql/rowsecurity.sql
M src/test/regress/sql/rules.sql
Fix crash in contrib/ltree's lca() function for empty input array.
commit : 330cad2c4b9a1ad2b690d7434fef7a2c481dc884
author : Tom Lane <[email protected]>
date : Fri, 13 Jul 2018 18:45:30 -0400
committer: Tom Lane <[email protected]>
date : Fri, 13 Jul 2018 18:45:30 -0400
lca_inner() wasn't prepared for the possibility of getting no inputs.
Fix that, and make some cosmetic improvements to the code while at it.
Also, I thought the documentation of this function as returning the
"longest common prefix" of the paths was entirely misleading; it really
returns a path one shorter than the longest common prefix, for the typical
definition of "prefix". Don't use that term in the docs, and adjust the
examples to clarify what really happens.
This has been broken since its beginning, so back-patch to all supported
branches.
Per report from Hailong Li. Thanks to Pierre Ducroquet for diagnosing
and for the initial patch, though I whacked it around some and added
test cases.
Discussion: https://postgr.es/m/[email protected]
M contrib/ltree/expected/ltree.out
M contrib/ltree/ltree_op.c
M contrib/ltree/sql/ltree.sql
M doc/src/sgml/ltree.sgml
Fix inadequate buffer locking in FSM and VM page re-initialization.
commit : 073ffefd80828dd16d6ad692b2d91501284ab7e2
author : Tom Lane <[email protected]>
date : Fri, 13 Jul 2018 11:52:50 -0400
committer: Tom Lane <[email protected]>
date : Fri, 13 Jul 2018 11:52:50 -0400
When reading an existing FSM or VM page that was found to be corrupt by the
buffer manager, the code applied PageInit() to reinitialize the page, but
did so without any locking. There is thus a hazard that two backends might
concurrently do PageInit, which in itself would still be OK, but the slower
one might then zero over subsequent data changes applied by the faster one.
Even that is unlikely to be fatal; but it's not desirable, so add locking
to prevent it.
This does not add any locking overhead in the normal code path where the
page is OK. It's not immediately obvious that that's safe, but I believe
it is, for reasons explained in the added comments.
Problem noted by R P Asim. It's been like this for a long time, so
back-patch to all supported branches.
Discussion: https://postgr.es/m/CANXE4Te4G0TGq6cr0-TvwP0H4BNiK_-hB5gHe8mF+nz0mcYfMQ@mail.gmail.com
M src/backend/access/heap/visibilitymap.c
M src/backend/storage/freespace/freespace.c
docs: Remove "New" description of the libpqxx interface
commit : 9348020cc062e89f30c8588cb8da6c2a983679ce
author : Bruce Momjian <[email protected]>
date : Fri, 13 Jul 2018 11:16:55 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 13 Jul 2018 11:16:55 -0400
Backpatch-through: 9.3
M doc/src/sgml/external-projects.sgml
Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.
commit : 5593280e203d0f7d93dea1f1387e0a7948a2d3af
author : Tom Lane <[email protected]>
date : Thu, 12 Jul 2018 12:28:43 -0400
committer: Tom Lane <[email protected]>
date : Thu, 12 Jul 2018 12:28:43 -0400
Explain that you can use any integer expression for the "count" in
pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only
allow a constant.
Remove the duplicate version of this para under MOVE. I don't see
a good reason to maintain two identical paras when we just said that
MOVE works exactly like FETCH.
Per Pavel Stehule, though I didn't use his text.
Discussion: https://postgr.es/m/CAFj8pRAcvSXcNdUGx43bOK1e3NNPbQny7neoTLN42af+8MYWEA@mail.gmail.com
M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/ref/fetch.sgml
Make logical WAL sender report streaming state appropriately
commit : d5eb1fe0dc717acae5da610c47468d3472d646a4
author : Michael Paquier <[email protected]>
date : Thu, 12 Jul 2018 10:20:14 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 12 Jul 2018 10:20:14 +0900
WAL senders sending logically-decoded data fail to properly report in
"streaming" state when starting up, hence as long as one extra record is
not replayed, such WAL senders would remain in a "catchup" state, which
is inconsistent with the physical cousin.
This can be easily reproduced by for example using pg_recvlogical and
restarting the upstream server. The TAP tests have been slightly
modified to detect the failure and strengthened so as future tests also
make sure that a node is in streaming state when waiting for its
catchup.
Backpatch down to 9.4 where this code has been introduced.
Reported-by: Sawada Masahiko
Author: Simon Riggs, Sawada Masahiko
Reviewed-by: Petr Jelinek, Michael Paquier, Vaishnavi Prabakaran
Discussion: https://postgr.es/m/CAD21AoB2ZbCCqOx=bgKMcLrAvs1V0ZMqzs7wBTuDySezTGtMZA@mail.gmail.com
M src/backend/replication/walsender.c
Fix create_scan_plan's handling of sortgrouprefs for physical tlists.
commit : 4b8860e2dd910a2b6c417b0bac98f12ea55edebb
author : Tom Lane <[email protected]>
date : Wed, 11 Jul 2018 15:25:29 -0400
committer: Tom Lane <[email protected]>
date : Wed, 11 Jul 2018 15:25:29 -0400
We should only run apply_pathtarget_labeling_to_tlist if CP_LABEL_TLIST
was specified, because only in that case has use_physical_tlist checked
that the labeling will succeed; otherwise we may get an "ORDER/GROUP BY
expression not found in targetlist" error. (This subsumes the previous
test about gating_clauses, because we reset "flags" to zero earlier
if there are gating clauses to apply.)
The only known case in which a failure can occur is with a ProjectSet
path directly atop a table scan path, although it seems likely that there
are other cases or will be such in future. This means that the failure
is currently only visible in the v10 branch: 9.6 didn't have ProjectSet,
while in v11 and HEAD, apply_scanjoin_target_to_paths for some weird
reason is using create_projection_path not apply_projection_to_path,
masking the problem because there's a ProjectionPath in between.
Nonetheless this code is clearly wrong on its own terms, so back-patch
to 9.6 where this logic was introduced.
Per report from Regina Obe.
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/plan/createplan.c
Fix typos
commit : d93c05635f4290109ee39d95bf181543428a6977
author : Peter Eisentraut <[email protected]>
date : Tue, 10 Jul 2018 11:14:53 +0200
committer: Peter Eisentraut <[email protected]>
date : Tue, 10 Jul 2018 11:14:53 +0200
M config/c-compiler.m4
M src/include/pg_config.h.in
Fix typo
commit : 8caf262097d828174c0e2dcc198a032246ed9bca
author : Peter Eisentraut <[email protected]>
date : Wed, 4 Jul 2018 22:13:16 +0200
committer: Peter Eisentraut <[email protected]>
date : Wed, 4 Jul 2018 22:13:16 +0200
M config/c-compiler.m4
M src/include/pg_config.h.in
Avoid emitting a bogus WAL record when recycling an all-zero btree page.
commit : 568995be6703593c01cbb4346c4ede3b44e168a9
author : Tom Lane <[email protected]>
date : Mon, 9 Jul 2018 19:26:19 -0400
committer: Tom Lane <[email protected]>
date : Mon, 9 Jul 2018 19:26:19 -0400
Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for
a page that it was about to recycle. However, it failed to distinguish
all-zero pages from dead pages, which is important because only the
latter have valid btpo.xact values, or indeed any special space at all.
Recycling an all-zero page with XLogStandbyInfoActive() enabled therefore
led to an Assert failure, or to emission of a WAL record containing a
bogus cutoff XID, which might lead to unnecessary query cancellations
on hot standby servers.
Per reports from Antonin Houska and 自己. Amit Kapila was first to
propose this fix, and Robert Haas, myself, and Kyotaro Horiguchi
reviewed it at various times.
This is an old bug, so back-patch to all supported branches.
Discussion: https://postgr.es/m/2628.1474272158@localhost
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/nbtree/nbtpage.c
Prevent accidental linking of system-supplied copies of libpq.so etc.
commit : ccc286da1d35b5d57a1e3322027905c00507d38f
author : Tom Lane <[email protected]>
date : Mon, 9 Jul 2018 17:23:31 -0400
committer: Tom Lane <[email protected]>
date : Mon, 9 Jul 2018 17:23:31 -0400
Back-patch commit dddfc4cb2, which broke LDFLAGS and related Makefile
variables into two parts, one for within-build-tree library references and
one for external libraries, to ensure that the order of -L flags has all
of the former before all of the latter. This turns out to fix a problem
recently noted on buildfarm member peripatus, that we attempted to
incorporate code from libpgport.a into a shared library. That will fail on
platforms that are sticky about putting non-PIC code into shared libraries.
(It's quite surprising we hadn't seen such failures before, since the code
in question has been like that for a long time.)
I think that peripatus' problem could have been fixed with just a subset
of this patch; but since the previous issue of accidentally linking to the
wrong copy of a Postgres shlib seems likely to bite people in the field,
let's just back-patch the whole change. Now that commit dddfc4cb2 has
survived some beta testing, I'm less afraid to back-patch it than I was
at the time.
This also fixes undesired inclusion of "-DFRONTEND" in pg_config's CPPFLAGS
output (in 9.6 and up) and undesired inclusion of "-L../../src/common" in
its LDFLAGS output (in all supported branches).
Back-patch to v10 and older branches; this is already in v11.
Discussion: https://postgr.es/m/[email protected]
M contrib/dblink/Makefile
M contrib/hstore_plperl/Makefile
M contrib/hstore_plpython/Makefile
M contrib/ltree_plpython/Makefile
M contrib/oid2name/Makefile
M contrib/postgres_fdw/Makefile
M contrib/spi/Makefile
M contrib/vacuumlo/Makefile
M src/Makefile.global.in
M src/Makefile.shlib
M src/backend/replication/libpqwalreceiver/Makefile
M src/bin/pg_basebackup/Makefile
M src/bin/pg_ctl/Makefile
M src/bin/pg_dump/Makefile
M src/bin/pg_rewind/Makefile
M src/bin/pg_upgrade/Makefile
M src/bin/pgbench/Makefile
M src/bin/psql/Makefile
M src/bin/scripts/Makefile
M src/common/Makefile
M src/interfaces/ecpg/compatlib/Makefile
M src/interfaces/ecpg/ecpglib/Makefile
M src/interfaces/ecpg/pgtypeslib/Makefile
M src/interfaces/ecpg/test/Makefile.regress
M src/interfaces/ecpg/test/compat_informix/Makefile
M src/interfaces/libpq/test/Makefile
M src/makefiles/pgxs.mk
M src/test/examples/Makefile
M src/tools/findoidjoins/Makefile
Rework order of end-of-recovery actions to delay timeline history write
commit : 619dea4678c345d119036311c503b55b974695d3
author : Michael Paquier <[email protected]>
date : Mon, 9 Jul 2018 10:26:41 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 9 Jul 2018 10:26:41 +0900
A critical failure in some of the end-of-recovery actions before the
end-of-recovery record is written can cause PostgreSQL to react
inconsistently with the rest of the cluster in the event of a crash
before the final record is written. Two such failures are for example
an error while processing a two-phase state files or when operating on
recovery.conf. With this commit, the failures are still considered
FATAL, but the write of the timeline history file is delayed as much as
possible so as the window between the moment the file is written and the
end-of-recovery record is generated gets minimized. This way, in the
event of a crash or a failure, the new timeline decided at promotion
will not seem taken by other nodes in the cluster. It is not really
possible to reduce to zero this window, hence one could still see
failures if a crash happens between the history file write and the
end-of-recovery record, so any future code should be careful when
adding new end-of-recovery actions. The original report from Magnus
Hagander mentioned a renamed recovery.conf as original end-of-recovery
failure which caused a timeline to be seen as taken but the subsequent
processing on the now-missing recovery.conf cause the startup process to
issue stop on FATAL, which at follow-up startup made the system
inconsistent because of on-disk changes which already happened.
Processing of two-phase state files still needs some work as corrupted
entries are simply ignored now. This is left as a future item and this
commit fixes the original complain.
Reported-by: Magnus Hagander
Author: Heikki Linnakangas
Reviewed-by: Alexander Korotkov, Michael Paquier, David Steele
Discussion: https://postgr.es/m/CABUevEz09XY2EevA2dLjPCY-C5UO4Hq=XxmXLmF6ipNFecbShQ@mail.gmail.com
M src/backend/access/transam/xlog.c
Add note in pg_rewind documentation about read-only files
commit : 741ad15f3b83e18b4009c42a287151e14f60fed1
author : Michael Paquier <[email protected]>
date : Sat, 7 Jul 2018 08:10:47 +0900
committer: Michael Paquier <[email protected]>
date : Sat, 7 Jul 2018 08:10:47 +0900
When performing pg_rewind, the presence of a read-only file which is not
accessible for writes will cause a failure while processing. This can
cause the control file of the target data folder to be truncated,
causing it to not be reusable with a successive run.
Also, when pg_rewind fails mid-flight, there is likely no way to be able
to recover the target data folder anyway, in which case a new base
backup is the best option. A note is added in the documentation as
well about.
Reported-by: Christian H.
Author: Michael Paquier
Reviewed-by: Andrew Dunstan
Discussion: https://postgr.es/m/20180104200633.17004.16377%40wrigleys.postgresql.org
M doc/src/sgml/ref/pg_rewind.sgml
logical decoding: beware of an unset specinsert change
commit : 95b6a40915cd03b9d1d09fc0bb4bcc374ee2165b
author : Alvaro Herrera <[email protected]>
date : Thu, 5 Jul 2018 17:42:37 -0400
committer: Alvaro Herrera <[email protected]>
date : Thu, 5 Jul 2018 17:42:37 -0400
Coverity complains that there is no protection in the code (at least in
non-assertion-enabled builds) against speculative insertion failing to
follow the expected protocol. Add an elog(ERROR) for the case.
M src/backend/replication/logical/reorderbuffer.c
Reduce cost of test_decoding's new oldest_xmin test
commit : 301b2a1aad77eeda54b02027597eb65e976a8c7b
author : Alvaro Herrera <[email protected]>
date : Thu, 5 Jul 2018 16:37:32 -0400
committer: Alvaro Herrera <[email protected]>
date : Thu, 5 Jul 2018 16:37:32 -0400
Change a whole-database VACUUM into doing just pg_attribute, which is
the portion that verifies what we want it to do. The original
formulation wastes a lot of CPU time, which leads the test to fail when
runtime exceeds isolationtester timeout when it's super-slow, such as
under CLOBBER_CACHE_ALWAYS. Per buildfarm member friarbird.
It turns out that the previous shape of the test doesn't always detect
the condition it is supposed to detect (on unpatched reorderbuffer
code): the reason is that there is a good chance of encountering a
xl_running_xacts record (logged every 15 seconds) before the checkpoint
-- and because we advance the xmin when we receive that WAL record, and
we *don't* advance the xmin twice consecutively without receiving a
client message in between, that means the xmin is not advanced enough
for the tuple to be pruned from pg_attribute by VACUUM. So the test
would spuriously pass.
The reason this test deficiency wasn't detected earlier is that HOT
pruning removes the tuple anyway, even if vacuum leaves it in place, so
the test correctly fails (detecting the coding mistake), but for the
wrong reason.
To fix this mess, run the s0_get_changes step twice before vacuum
instead of once: this seems to cause the xmin to be advanced reliably,
wreaking havoc with more certainty.
Author: Arseny Sher
Discussion: https://postgr.es/m/87h8lkuxoa.fsf@ars-thinkpad
M contrib/test_decoding/expected/oldest_xmin.out
M contrib/test_decoding/specs/oldest_xmin.spec
Prevent references to invalid relation pages after fresh promotion
commit : 8d68ee6f31ca4614db0b486581235ca79d1e735e
author : Michael Paquier <[email protected]>
date : Thu, 5 Jul 2018 10:47:19 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 5 Jul 2018 10:47:19 +0900
If a standby crashes after promotion before having completed its first
post-recovery checkpoint, then the minimal recovery point which marks
the LSN position where the cluster is able to reach consistency may be
set to a position older than the first end-of-recovery checkpoint while
all the WAL available should be replayed. This leads to the instance
thinking that it contains inconsistent pages, causing a PANIC and a hard
instance crash even if all the WAL available has not been replayed for
certain sets of records replayed. When in crash recovery,
minRecoveryPoint is expected to always be set to InvalidXLogRecPtr,
which forces the recovery to replay all the WAL available, so this
commit makes sure that the local copy of minRecoveryPoint from the
control file is initialized properly and stays as it is while crash
recovery is performed. Once switching to archive recovery or if crash
recovery finishes, then the local copy minRecoveryPoint can be safely
updated.
Pavan Deolasee has reported and diagnosed the failure in the first
place, and the base fix idea to rely on the local copy of
minRecoveryPoint comes from Kyotaro Horiguchi, which has been expanded
into a full-fledged patch by me. The test included in this commit has
been written by Álvaro Herrera and Pavan Deolasee, which I have modified
to make it faster and more reliable with sleep phases.
Backpatch down to all supported versions where the bug appears, aka 9.3
which is where the end-of-recovery checkpoint is not run by the startup
process anymore. The test gets easily supported down to 10, still it
has been tested on all branches.
Reported-by: Pavan Deolasee
Diagnosed-by: Pavan Deolasee
Reviewed-by: Pavan Deolasee, Kyotaro Horiguchi
Author: Michael Paquier, Kyotaro Horiguchi, Pavan Deolasee, Álvaro
Herrera
Discussion: https://postgr.es/m/CABOikdPOewjNL=05K5CbNMxnNtXnQjhTx2F--4p4ruorCjukbA@mail.gmail.com
M src/backend/access/transam/xlog.c
Check for interrupts inside the nbtree page deletion code.
commit : 2adadf018bd48e634231ece3df4814954bb20041
author : Andres Freund <[email protected]>
date : Wed, 4 Jul 2018 14:53:49 -0700
committer: Andres Freund <[email protected]>
date : Wed, 4 Jul 2018 14:53:49 -0700
When deleting pages the nbtree code has to walk through siblings of a
tree node. When those sibling links are corrupted that can lead to
endless loops - which are currently not interruptible. This is
especially problematic if autovacuum is repeatedly blocked on such
indexes, as it can be hard to get out of that situation without
resorting to single user mode.
Thus add interrupt checks to appropriate places in such
loops. Unfortunately in one of the cases it's it's not easy to do so.
Between 9.3 and 9.4 the page deletion (and page split) code changed
significantly. Before it was significantly less robust against
interruptions. Therefore don't backpatch to 9.3.
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch: 9.4-
M src/backend/access/nbtree/nbtpage.c
Improve the performance of relation deletes during recovery.
commit : 7da22d866d45d940ba40b77881fbb2be803304a5
author : Fujii Masao <[email protected]>
date : Thu, 5 Jul 2018 02:21:15 +0900
committer: Fujii Masao <[email protected]>
date : Thu, 5 Jul 2018 02:21:15 +0900
When multiple relations are deleted at the same transaction,
the files of those relations are deleted by one call to smgrdounlinkall(),
which leads to scan whole shared_buffers only one time. OTOH,
previously, during recovery, smgrdounlink() (not smgrdounlinkall()) was
called for each file to delete, which led to scan shared_buffers
multiple times. Obviously this could cause to increase the WAL replay
time very much especially when shared_buffers was huge.
To alleviate this situation, this commit changes the recovery so that
it also calls smgrdounlinkall() only one time to delete multiple
relation files.
This is just fix for oversight of commit 279628a0a7, not new feature.
So, per discussion on pgsql-hackers, we concluded to backpatch this
to all supported versions.
Author: Fujii Masao
Reviewed-by: Michael Paquier, Andres Freund, Thomas Munro, Kyotaro Horiguchi, Takayuki Tsunakawa
Discussion: https://postgr.es/m/CAHGQGwHVQkdfDqtvGVkty+19cQakAydXn1etGND3X0PHbZ3+6w@mail.gmail.com
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/storage/smgr/md.c
M src/include/storage/smgr.h
Fix libpq example programs
commit : d7e5805399b4e699bcb6aa2d90d442ce60c3f072
author : Peter Eisentraut <[email protected]>
date : Sun, 1 Jul 2018 14:06:40 +0200
committer: Peter Eisentraut <[email protected]>
date : Sun, 1 Jul 2018 14:06:40 +0200
When these programs call pg_catalog.set_config, they need to check for
PGRES_TUPLES_OK instead of PGRES_COMMAND_OK. Fix for
5770172cb0c9df9e6ce27c507b449557e5b45124.
Reported-by: Ideriha, Takeshi <[email protected]>
M doc/src/sgml/libpq.sgml
M doc/src/sgml/lobj.sgml
M src/test/examples/testlibpq.c
M src/test/examples/testlibpq2.c
M src/test/examples/testlibpq4.c
M src/test/examples/testlo.c
M src/test/examples/testlo64.c
Replace search.cpan.org with metacpan.org
commit : 7e0786e4d9de74528db649f10dcba906eb3aa52c
author : Michael Paquier <[email protected]>
date : Fri, 29 Jun 2018 22:17:54 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 29 Jun 2018 22:17:54 +0900
search.cpan.org has been EOL'd, with metacpan.org being the official
replacement to which URLs now redirect. Update links to match the new
URL. Also update links to CPAN to use https as it will redirect from
http.
Author: Daniel Gustafsson
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/acronyms.sgml
M doc/src/sgml/external-projects.sgml
M doc/src/sgml/install-windows.sgml
Fix "base" snapshot handling in logical decoding
commit : da10d6a8a94eec016fa072d007bced9159a28d39
author : Alvaro Herrera <[email protected]>
date : Tue, 26 Jun 2018 16:38:34 -0400
committer: Alvaro Herrera <[email protected]>
date : Tue, 26 Jun 2018 16:38:34 -0400
Two closely related bugs are fixed. First, xmin of logical slots was
advanced too early. During xl_running_xacts processing, xmin of the
slot was set to the oldest running xid in the record, but that's wrong:
actually, snapshots which will be used for not-yet-replayed transactions
might consider older txns as running too, so we need to keep xmin back
for them. The problem wasn't noticed earlier because DDL which allows
to delete tuple (set xmax) while some another not-yet-committed
transaction looks at it is pretty rare, if not unique: e.g. all forms of
ALTER TABLE which change schema acquire ACCESS EXCLUSIVE lock
conflicting with any inserts. The included test case (test_decoding's
oldest_xmin) uses ALTER of a composite type, which doesn't have such
interlocking.
To deal with this, we must be able to quickly retrieve oldest xmin
(oldest running xid among all assigned snapshots) from ReorderBuffer. To
fix, add another list of ReorderBufferTXNs to the reorderbuffer, where
transactions are sorted by base-snapshot-LSN. This is slightly
different from the existing (sorted by first-LSN) list, because a
transaction can have an earlier LSN but a later Xmin, if its first
record does not obtain an xmin (eg. xl_xact_assignment). Note this new
list doesn't fully replace the existing txn list: we still need that one
to prevent WAL recycling.
The second issue concerns SnapBuilder snapshots and subtransactions.
SnapBuildDistributeNewCatalogSnapshot never assigned a snapshot to a
transaction that is known to be a subtxn, which is good in the common
case that the top-level transaction already has one (no point in doing
so), but a bug otherwise. To fix, arrange to transfer the snapshot from
the subtxn to its top-level txn as soon as the kinship gets known.
test_decoding's snapshot_transfer verifies this.
Also, fix a minor memory leak: refcount of toplevel's old base snapshot
was not decremented when the snapshot is transferred from child.
Liberally sprinkle code comments, and rewrite a few existing ones. This
part is my (Álvaro's) contribution to this commit, as I had to write all
those comments in order to understand the existing code and Arseny's
patch.
Reported-by: Arseny Sher <[email protected]>
Diagnosed-by: Arseny Sher <[email protected]>
Co-authored-by: Arseny Sher <[email protected]>
Co-authored-by: Álvaro Herrera <[email protected]>
Reviewed-by: Antonin Houska <[email protected]>
Discussion: https://postgr.es/m/87lgdyz1wj.fsf@ars-thinkpad
M contrib/test_decoding/Makefile
A contrib/test_decoding/expected/oldest_xmin.out
A contrib/test_decoding/expected/snapshot_transfer.out
A contrib/test_decoding/specs/oldest_xmin.spec
A contrib/test_decoding/specs/snapshot_transfer.spec
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
M src/include/replication/reorderbuffer.h
Fix documentation bug related to backup history file.
commit : d06d92cd2d5e3c3dd893ee0d82d14d1f8adbc82b
author : Fujii Masao <[email protected]>
date : Wed, 27 Jun 2018 00:45:21 +0900
committer: Fujii Masao <[email protected]>
date : Wed, 27 Jun 2018 00:45:21 +0900
The backup history file has been no longer necessary for recovery
since the version 9.0. It's now basically just for informational purpose.
But previously the documentations still described that a recovery
requests the backup history file to proceed. The commit fixes this
documentation bug.
Back-patch to all supported versions.
Author: Yugo Nagata
Reviewed-by: Kyotaro Horiguchi
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/backup.sgml
M doc/src/sgml/high-availability.sgml
Add PGTYPESchar_free() to avoid cross-module problems on Windows.
commit : b5b973ef0ba736c7c002f0907014d3115471644e
author : Thomas Munro <[email protected]>
date : Mon, 18 Jun 2018 18:33:53 +1200
committer: Thomas Munro <[email protected]>
date : Mon, 18 Jun 2018 18:33:53 +1200
On Windows, it is sometimes important for corresponding malloc() and
free() calls to be made from the same DLL, since some build options can
result in multiple allocators being active at the same time. For that
reason we already provided PQfreemem(). This commit adds a similar
function for freeing string results allocated by the pgtypes library.
Author: Takayuki Tsunakawa
Reviewed-by: Kyotaro Horiguchi
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8AD5D6%40G01JPEXMBYT05
M doc/src/sgml/ecpg.sgml
M src/interfaces/ecpg/include/Makefile
A src/interfaces/ecpg/include/pgtypes.h
M src/interfaces/ecpg/include/pgtypes_date.h
M src/interfaces/ecpg/include/pgtypes_interval.h
M src/interfaces/ecpg/include/pgtypes_numeric.h
M src/interfaces/ecpg/include/pgtypes_timestamp.h
M src/interfaces/ecpg/pgtypeslib/common.c
M src/interfaces/ecpg/pgtypeslib/exports.txt
M src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-dt_test2.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c
M src/interfaces/ecpg/test/expected/preproc-outofscope.c
M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc
M src/interfaces/ecpg/test/pgtypeslib/dt_test2.pgc
M src/interfaces/ecpg/test/pgtypeslib/num_test.pgc
M src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc
M src/interfaces/ecpg/test/sql/sqlda.pgc
Move RecoveryLockList into a hash table.
commit : 35750a38b7ab6e30aa2ee6eb7765ebd2172dd7c5
author : Thomas Munro <[email protected]>
date : Tue, 26 Jun 2018 18:44:31 +1200
committer: Thomas Munro <[email protected]>
date : Tue, 26 Jun 2018 18:44:31 +1200
Standbys frequently need to release all locks held by a given xid.
Instead of searching one big list linearly, let's create one list
per xid and put them in a hash table, so we can find what we need
in O(1) time.
Earlier analysis and a prototype were done by David Rowley, though
this isn't his patch.
Back-patch all the way.
Author: Thomas Munro
Diagnosed-by: David Rowley, Andres Freund
Reviewed-by: Andres Freund, Tom Lane, Robert Haas
Discussion: https://postgr.es/m/CAEepm%3D1mL0KiQ2KJ4yuPpLGX94a4Ns_W6TL4EGRouxWibu56pA%40mail.gmail.com
Discussion: https://postgr.es/m/CAKJS1f9vJ841HY%3DwonnLVbfkTWGYWdPN72VMxnArcGCjF3SywA%40mail.gmail.com
M src/backend/storage/ipc/standby.c
Address set of issues with errno handling
commit : 7fdf56b0a796f9e6f625c8fa236ece72b91b2270
author : Michael Paquier <[email protected]>
date : Mon, 25 Jun 2018 11:20:50 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 25 Jun 2018 11:20:50 +0900
System calls mixed up in error code paths are causing two issues which
several code paths have not correctly handled:
1) For write() calls, sometimes the system may return less bytes than
what has been written without errno being set. Some paths were careful
enough to consider that case, and assumed that errno should be set to
ENOSPC, other calls missed that.
2) errno generated by a system call is overwritten by other system calls
which may succeed once an error code path is taken, causing what is
reported to the user to be incorrect.
This patch uses the brute-force approach of correcting all those code
paths. Some refactoring could happen in the future, but this is let as
future work, which is not targeted for back-branches anyway.
Author: Michael Paquier
Reviewed-by: Ashutosh Sharma
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/heap/rewriteheap.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogutils.c
M src/backend/replication/basebackup.c
M src/backend/replication/logical/origin.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
M src/backend/replication/slot.c
M src/bin/pg_basebackup/receivelog.c
doc: adjust order of NUMERIC arguments to match syntax
commit : 037768cf75707cb00ef5c1c1d70b0c6a6800206b
author : Bruce Momjian <[email protected]>
date : Sun, 24 Jun 2018 18:07:00 -0400
committer: Bruce Momjian <[email protected]>
date : Sun, 24 Jun 2018 18:07:00 -0400
Specifically, mention precision before scale
Reported-by: [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.3
M doc/src/sgml/datatype.sgml
doc: show how interval's 3 unit buckets behave using EXTRACT()
commit : ae36661661c5ffbb06535a9f7aa9b12dfa1fb98c
author : Bruce Momjian <[email protected]>
date : Sat, 23 Jun 2018 23:32:41 -0400
committer: Bruce Momjian <[email protected]>
date : Sat, 23 Jun 2018 23:32:41 -0400
This clarifies when justify_days() and justify_hours() are useful.
Paragraph moved too.
Reported-by: [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.3
M doc/src/sgml/datatype.sgml
Fix typo
commit : 39686cd7f06fb8d3c0762b4d64056ed01f085966
author : Magnus Hagander <[email protected]>
date : Wed, 20 Jun 2018 16:07:07 +0200
committer: Magnus Hagander <[email protected]>
date : Wed, 20 Jun 2018 16:07:07 +0200
Reported using the website comment form
M doc/src/sgml/dml.sgml
doc: explain use of json_populate_record{set}()
commit : 4832c4c191d7854e574dc0b4cad7f63ae51c5221
author : Bruce Momjian <[email protected]>
date : Tue, 19 Jun 2018 13:43:40 -0400
committer: Bruce Momjian <[email protected]>
date : Tue, 19 Jun 2018 13:43:40 -0400
The set-returning nature of these functions make their use unclear. The
modified paragraph was added in PG 9.4.
Reported-by: [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/func.sgml
Fix contrib/hstore_plperl to look through scalar refs.
commit : 1bebfb9b63657c9d3257e3ba374e477138ca22af
author : Tom Lane <[email protected]>
date : Mon, 18 Jun 2018 15:55:06 -0400
committer: Tom Lane <[email protected]>
date : Mon, 18 Jun 2018 15:55:06 -0400
Bring this transform function into sync with the policy established
by commit 3a382983d.
Also, fix it to make sure that what it drills down to is indeed a
hash, and not some other kind of Perl SV. Previously, the test
cases added here provoked crashes.
Because of the crash hazard, back-patch to 9.5 where this module
was introduced.
Discussion: https://postgr.es/m/[email protected]
M contrib/hstore_plperl/expected/hstore_plperl.out
M contrib/hstore_plperl/hstore_plperl.c
M contrib/hstore_plperl/sql/hstore_plperl.sql
Prevent hard failures of standbys caused by recycled WAL segments
commit : 5860b22c455ff197d568dabcea591d2afc769f34
author : Michael Paquier <[email protected]>
date : Mon, 18 Jun 2018 10:43:27 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 18 Jun 2018 10:43:27 +0900
When a standby's WAL receiver stops reading WAL from a WAL stream, it
writes data to the current WAL segment without having priorily zero'ed
the page currently written to, which can cause the WAL reader to read
junk data from a past recycled segment and then it would try to get a
record from it. While sanity checks in place provide most of the
protection needed, in some rare circumstances, with chances increasing
when a record header crosses a page boundary, then the startup process
could fail violently on an allocation failure, as follows:
FATAL: invalid memory alloc request size XXX
This is confusing for the user and also unhelpful as this requires in
the worst case a manual restart of the instance, impacting potentially
the availability of the cluster, and this also makes WAL data look like
it is in a corrupted state.
The chances of seeing failures are higher if the connection between the
standby and its root node is unstable, causing WAL pages to be written
in the middle. A couple of approaches have been discussed, like
zero-ing new WAL pages within the WAL receiver itself but this has the
disadvantage of impacting performance of any existing instances as this
breaks the sequential writes done by the WAL receiver. This commit
deals with the problem with a more simple approach, which has no
performance impact without reducing the detection of the problem: if a
record is found with a length higher than 1GB for backends, then do not
try any allocation and report a soft failure which will force the
standby to retry reading WAL. It could be possible that the allocation
call passes and that an unnecessary amount of memory is allocated,
however follow-up checks on records would just fail, making this
allocation short-lived anyway.
This patch owes a great deal to Tsunakawa Takayuki for reporting the
failure first, and then discussing a couple of potential approaches to
the problem.
Backpatch down to 9.5, which is where palloc_extended has been
introduced.
Reported-by: Tsunakawa Takayuki
Reviewed-by: Tsunakawa Takayuki
Author: Michael Paquier
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8B57AD@G01JPEXMBYT05
M src/backend/access/transam/xlogreader.c
Use -Wno-format-truncation and -Wno-stringop-truncation, if available.
commit : 119290be6fe3bea12053042f5d3eaa135a260a52
author : Tom Lane <[email protected]>
date : Sat, 16 Jun 2018 15:34:07 -0400
committer: Tom Lane <[email protected]>
date : Sat, 16 Jun 2018 15:34:07 -0400
gcc 8 has started emitting some warnings that are largely useless for
our purposes, particularly since they complain about code following
the project-standard coding convention that path names are assumed
to be shorter than MAXPGPATH. Even if we make the effort to remove
that assumption in some future release, the changes wouldn't get
back-patched. Hence, just suppress these warnings, on compilers that
have these switches.
Backpatch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M configure
M configure.in
Avoid unnecessary use of strncpy in a couple of places in ecpg.
commit : 58065f9eed68fae83ddf98c8dff24ae8f0b62f0c
author : Tom Lane <[email protected]>
date : Sat, 16 Jun 2018 14:58:11 -0400
committer: Tom Lane <[email protected]>
date : Sat, 16 Jun 2018 14:58:11 -0400
Use of strncpy with a length limit based on the source, rather than
the destination, is non-idiomatic and draws warnings from gcc 8.
Replace with memcpy, which does exactly the same thing in these cases,
but with less chance for confusion.
Backpatch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/ecpg/ecpglib/descriptor.c
M src/interfaces/ecpg/pgtypeslib/common.c
Use snprintf not sprintf in pg_waldump's timestamptz_to_str.
commit : 8870e2978fc5db5741229f5cddc7bcc24ee52000
author : Tom Lane <[email protected]>
date : Sat, 16 Jun 2018 14:45:47 -0400
committer: Tom Lane <[email protected]>
date : Sat, 16 Jun 2018 14:45:47 -0400
This could only cause an issue if strftime returned a ridiculously
long timezone name, which seems unlikely; and it wouldn't qualify
as a security problem even then, since pg_waldump (nee pg_xlogdump)
is a debug tool not part of the server. But gcc 8 has started issuing
warnings about it, so let's use snprintf and be safe.
Backpatch to 9.3 where this code was added.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_xlogdump/compat.c
Fail BRIN control functions during recovery explicitly
commit : e951f66deadbe78da83b2d1919d39883d098fdff
author : Alvaro Herrera <[email protected]>
date : Thu, 14 Jun 2018 12:51:32 -0400
committer: Alvaro Herrera <[email protected]>
date : Thu, 14 Jun 2018 12:51:32 -0400
They already fail anyway, but prior to this patch they raise an ugly
error message about a lock that cannot be acquired. This just improves
the message.
Author: Masahiko Sawada
Reported-by: Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoBZau4g4_NUf3BKNd=CdYK+xaPdtJCzvOC1TxGdTiJx_Q@mail.gmail.com
Reviewed-by: Kuntal Ghosh, Alexander Korotkov, Simon Riggs, Michaël Paquier, Álvaro Herrera
M src/backend/access/brin/brin.c
Documentation improvement for pg_trgm
commit : c7699d9acf0416670f7babd4999a913085aa08e7
author : Alexander Korotkov <[email protected]>
date : Wed, 13 Jun 2018 18:31:18 +0300
committer: Alexander Korotkov <[email protected]>
date : Wed, 13 Jun 2018 18:31:18 +0300
Documentation of word_similarity() and strict_word_similarity() functions
contains some vague wordings which could confuse users. This patch makes
those wordings more clear. word_similarity() was introduced in PostgreSQL 9.6,
and corresponding part of documentation needs to be backpatched.
Author: Bruce Momjian, Alexander Korotkov
Discussion: https://postgr.es/m/20180526165648.GB12510%40momjian.us
Backpatch: 9.6, where word_similarity() was introduced
M doc/src/sgml/pgtrgm.sgml
Fix bugs in vacuum of shared rels, by keeping their relcache entries current.
commit : 6a46aba1cd6dd7c5af5d52111a8157808cbc5e10
author : Andres Freund <[email protected]>
date : Tue, 12 Jun 2018 11:13:21 -0700
committer: Andres Freund <[email protected]>
date : Tue, 12 Jun 2018 11:13:21 -0700
When vacuum processes a relation it uses the corresponding relcache
entry's relfrozenxid / relminmxid as a cutoff for when to remove
tuples etc. Unfortunately for nailed relations (i.e. critical system
catalogs) bugs could frequently lead to the corresponding relcache
entry being stale.
This set of bugs could cause actual data corruption as vacuum would
potentially not remove the correct row versions, potentially reviving
them at a later point. After 699bf7d05c some corruptions in this vein
were prevented, but the additional error checks could also trigger
spuriously. Examples of such errors are:
ERROR: found xmin ... from before relfrozenxid ...
and
ERROR: found multixact ... from before relminmxid ...
To be caused by this bug the errors have to occur on system catalog
tables.
The two bugs are:
1) Invalidations for nailed relations were ignored, based on the
theory that the relcache entry for such tables doesn't
change. Which is largely true, except for fields like relfrozenxid
etc. This means that changes to relations vacuumed in other
sessions weren't picked up by already existing sessions. Luckily
autovacuum doesn't have particularly longrunning sessions.
2) For shared *and* nailed relations, the shared relcache init file
was never invalidated while running. That means that for such
tables (e.g. pg_authid, pg_database) it's not just already existing
sessions that are affected, but even new connections are as well.
That explains why the reports usually were about pg_authid et. al.
To fix 1), revalidate the rd_rel portion of a relcache entry when
invalid. This implies a bit of extra complexity to deal with
bootstrapping, but it's not too bad. The fix for 2) is simpler,
simply always remove both the shared and local init files.
Author: Andres Freund
Reviewed-By: Alvaro Herrera
Discussion:
https://postgr.es/m/[email protected]
https://postgr.es/m/CAMa1XUhKSJd98JW4o9StWPrfS=11bPgG+_GDMxe25TvUY4Sugg@mail.gmail.com
https://postgr.es/m/CAKMFJucqbuoDRfxPDX39WhA3vJyxweRg_zDVXzncr6+5wOguWA@mail.gmail.com
https://postgr.es/m/CAGewt-ujGpMLQ09gXcUFMZaZsGJC98VXHEFbF-tpPB0fB13K+A@mail.gmail.com
Backpatch: 9.3-
M src/backend/utils/cache/inval.c
M src/backend/utils/cache/relcache.c
M src/include/storage/standbydefs.h
Fix grammar in documentation related to checkpoint_flush_after
commit : 256d43128d21891b6090e6fc19668e27da04764b
author : Michael Paquier <[email protected]>
date : Mon, 11 Jun 2018 09:54:25 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 11 Jun 2018 09:54:25 +0900
Reported-by: Christopher Jones
M doc/src/sgml/wal.sgml
Fix grammar in REVOKE documentation
commit : 5bb08c7000db0f3f6621316105de1711f7b559a5
author : Michael Paquier <[email protected]>
date : Sun, 10 Jun 2018 22:44:17 +0900
committer: Michael Paquier <[email protected]>
date : Sun, 10 Jun 2018 22:44:17 +0900
Reported-by: Erwin Brandstetter
M doc/src/sgml/ref/revoke.sgml
Fix function code in error report
commit : 1a552256f6deae287140a608504e7ea7e8b633a2
author : Alvaro Herrera <[email protected]>
date : Wed, 6 Jun 2018 14:46:53 -0400
committer: Alvaro Herrera <[email protected]>
date : Wed, 6 Jun 2018 14:46:53 -0400
This bug causes a lseek() failure to be reported as a "could not open"
failure in the error message, muddling bug reports. I introduced this
copy-and-pasteo in commit 78e122010422.
Noticed while reviewing code for bug report #15221, from lily liang. In
version 10 the affected function is only used by multixact.c and
commit_ts, and only in corner-case circumstances, neither of which are
involved in the reported bug (a pg_subtrans failure.)
Author: Álvaro Herrera
M src/backend/access/transam/slru.c
doc: mark 'replaceable' parameter for backup program listing
commit : be565fa89ddb2a462f1c47bd7810f94de77e191b
author : Bruce Momjian <[email protected]>
date : Mon, 28 May 2018 14:19:45 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 28 May 2018 14:19:45 -0400
Reported-by: Liudmila Mantrova
Discussion: https://postgr.es/m/[email protected]
Author: Liudmila Mantrova
Backpatch-through: 9.3
M doc/src/sgml/backup.sgml
doc: adjust DECLARE docs to mention FOR UPDATE behavior
commit : 7b614c78be50a3a1ababa5ff810640fcc5829194
author : Bruce Momjian <[email protected]>
date : Mon, 28 May 2018 13:16:02 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 28 May 2018 13:16:02 -0400
Reported-by: Peter Eisentraut
Discussion: https://postgr.es/m/[email protected]
Author: Peter Eisentraut, Tom Lane, me
Backpatch-through: 9.3
M doc/src/sgml/ref/declare.sgml
Fix misidentification of SQL statement type in plpgsql's exec_stmt_execsql.
commit : f9ecb6caba071304a8a5c502b78ffd3b06f0bb1c
author : Tom Lane <[email protected]>
date : Fri, 25 May 2018 14:31:07 -0400
committer: Tom Lane <[email protected]>
date : Fri, 25 May 2018 14:31:07 -0400
To distinguish SQL statements that are INSERT/UPDATE/DELETE from other
ones, exec_stmt_execsql looked at the post-rewrite form of the statement
rather than the original. This is problematic because it did that only
during first execution of the statement (in a session), but the correct
answer could change later due to addition or removal of DO INSTEAD rules
during the session. That could lead to an Assert failure, as reported
by Tushar Ahuja and Robert Haas. In non-assert builds, there's a hazard
that we would fail to enforce STRICT behavior when we'd be expected to.
That would happen if an initially present DO INSTEAD, that replaced the
original statement with one of a different type, were removed; after that
the statement should act "normally", including strictness enforcement, but
it didn't. (The converse case of enforcing strictness when we shouldn't
doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the
statement type would always lead to acting as though the statement returned
zero rows, so that the strictness error could not fire.)
To fix, inspect the original form of the statement not the post-rewrite
form, making it valid to assume the answer can't change intra-session.
This should lead to the same answer in every case except when there is a
DO INSTEAD that changes the statement type; we will now set mod_stmt=true
anyway, while we would not have done so before. That breaks the Assert
in the SPI_OK_REWRITTEN code path, which expected the latter behavior.
It might be all right to assert mod_stmt rather than !mod_stmt there,
but I'm not entirely convinced that that'd always hold, so just remove
the assertion altogether.
This has been broken for a long time, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/CA+TgmoZUrRN4xvZe_BbBn_Xp0BDwuMEue-0OyF0fJpfvU2Yc7Q@mail.gmail.com
M src/pl/plpgsql/src/pl_exec.c
Remove incorrect statement about IPC configuration on OpenBSD
commit : de1593d45587988f6e2450e78d623718df3e085e
author : Magnus Hagander <[email protected]>
date : Fri, 25 May 2018 13:59:50 +0200
committer: Magnus Hagander <[email protected]>
date : Fri, 25 May 2018 13:59:50 +0200
kern.ipc.shm_use_phys is not a sysctl on OpenBSD, and SEMMAP is not
a kernel configuration option. These were probably copy pasteos from
when the documentation had a single paragraph for *BSD.
Author: Daniel Gustafsson <[email protected]>
M doc/src/sgml/runtime.sgml
Properly schema-qualify additional object types in getObjectDescription().
commit : 3d3165210dccff489e3082b96f4b5c0d4ade37ff
author : Tom Lane <[email protected]>
date : Thu, 24 May 2018 12:07:41 -0400
committer: Tom Lane <[email protected]>
date : Thu, 24 May 2018 12:07:41 -0400
Collations, conversions, extended statistics objects (in >= v10),
and all four types of text search objects have schema-qualified names.
getObjectDescription() ignored that and would emit just the base name of
the object, potentially producing wrong or at least highly misleading
output. Fix it to add the schema name whenever the object is not "visible"
in the current search path, as is the rule for other schema-qualifiable
object types.
Although in common situations the output won't change, this seems to me
(tgl) to be a bug worthy of back-patching, hence do so.
Kyotaro Horiguchi, per a complaint from me
Discussion: https://postgr.es/m/[email protected]
M src/backend/catalog/objectaddress.c
M src/test/regress/expected/alter_generic.out
M src/test/regress/expected/alter_table.out
Fix simple_prompt() to disable echo on Windows when stdin != terminal.
commit : bbaf75ee0c3aa902f6d8935eb3f433149a461144
author : Tom Lane <[email protected]>
date : Wed, 23 May 2018 19:04:34 -0400
committer: Tom Lane <[email protected]>
date : Wed, 23 May 2018 19:04:34 -0400
If echo = false, simple_prompt() is supposed to prevent echoing the
input (for password input). However, the Windows implementation applied
the mode change to STD_INPUT_HANDLE. That would not have the desired
effect if stdin isn't actually the terminal, for instance if the user
is piping something into psql. Fix it to apply the mode change to
the correct input file, so that passwords do not echo in such cases.
In passing, shorten and de-uglify this code by using #elif rather than
an #if nest and removing some duplicated code.
Back-patch to all supported versions. To simplify that, also back-patch
the portions of commit 9daec77e1 that got rid of an unnecessary
malloc/free in the same area.
Matthew Stickney (cosmetic changes by me)
Discussion: https://postgr.es/m/[email protected]
M src/port/sprompt.c
Widen COPY FROM's current-line-number counter from 32 to 64 bits.
commit : 588edd83e541c421dafa85ed6ba2a04dab5af984
author : Tom Lane <[email protected]>
date : Tue, 22 May 2018 13:32:52 -0400
committer: Tom Lane <[email protected]>
date : Tue, 22 May 2018 13:32:52 -0400
Because the code for the HEADER option skips a line when this counter
is zero, a very long COPY FROM WITH HEADER operation would drop a line
every 2^32 lines. A lesser but still unfortunate problem is that errors
would show a wrong input line number for errors occurring beyond the
2^31'st input line. While such large input streams seemed impractical
when this code was first written, they're not any more. Widening the
counter (and some associated variables) to uint64 should be enough to
prevent problems for the foreseeable future.
David Rowley
Discussion: https://postgr.es/m/CAKJS1f88yh-6wwEfO6QLEEvH3BEugOq2QX1TOja0vCauoynmOQ@mail.gmail.com
M src/backend/commands/copy.c
Fix SQL:2008 FETCH FIRST syntax to allow parameters.
commit : 7a0aa8d12ace1e5e73ccf9cbee88fdde255fe172
author : Andrew Gierth <[email protected]>
date : Mon, 21 May 2018 17:02:17 +0100
committer: Andrew Gierth <[email protected]>
date : Mon, 21 May 2018 17:02:17 +0100
OFFSET <x> ROWS FETCH FIRST <y> ROWS ONLY syntax is supposed to accept
<simple value specification>, which includes parameters as well as
literals. When this syntax was added all those years ago, it was done
inconsistently, with <x> and <y> being different subsets of the
standard syntax.
Rectify that by making <x> and <y> accept the same thing, and allowing
either a (signed) numeric literal or a c_expr there, which allows for
parameters, variables, and parenthesized arbitrary expressions.
Per bug #15200 from Lukas Eder.
Backpatch all the way, since this has been broken from the start.
Discussion: https://postgr.es/m/[email protected]
Discussion: http://postgr.es/m/[email protected]
M doc/src/sgml/ref/select.sgml
M src/backend/parser/gram.y
Fix unsafe usage of strerror(errno) within ereport().
commit : 1545ca9a7463f4ae8451a845774a107ad0757a9f
author : Tom Lane <[email protected]>
date : Mon, 21 May 2018 00:32:28 -0400
committer: Tom Lane <[email protected]>
date : Mon, 21 May 2018 00:32:28 -0400
This is the converse of the unsafe-usage-of-%m problem: the reason
ereport/elog provide that format code is mainly to dodge the hazard
of errno getting changed before control reaches functions within the
arguments of the macro. I only found one instance of this hazard,
but it's been there since 9.4 :-(.
M src/backend/libpq/auth.c
printf("%lf") is not portable, so omit the "l".
commit : 9c515f77d6cffb6f2576c5e9895cc0f29cc6279c
author : Tom Lane <[email protected]>
date : Sun, 20 May 2018 11:40:54 -0400
committer: Tom Lane <[email protected]>
date : Sun, 20 May 2018 11:40:54 -0400
The "l" (ell) width spec means something in the corresponding scanf usage,
but not here. While modern POSIX says that applying "l" to "f" and other
floating format specs is a no-op, SUSv2 says it's undefined. Buildfarm
experience says that some old compilers emit warnings about it, and at
least one old stdio implementation (mingw's "ANSI" option) actually
produces wrong answers and/or crashes.
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ecpg.sgml
M src/interfaces/ecpg/test/compat_informix/sqlda.pgc
M src/interfaces/ecpg/test/expected/compat_informix-sqlda.c
M src/interfaces/ecpg/test/expected/preproc-outofscope.c
M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/preproc/outofscope.pgc
M src/interfaces/ecpg/test/sql/sqlda.pgc
Support platforms where strtoll/strtoull are spelled __strtoll/__strtoull.
commit : 22d22e4bddf65559453506f4090a6cae0f010b96
author : Tom Lane <[email protected]>
date : Sat, 19 May 2018 14:22:18 -0400
committer: Tom Lane <[email protected]>
date : Sat, 19 May 2018 14:22:18 -0400
Ancient HPUX, for one, does this. We hadn't noticed due to the lack
of regression tests that required a working strtoll.
(I was slightly tempted to remove the other historical spelling,
strto[u]q, since it seems we have no buildfarm members testing that case.
But I refrained.)
Discussion: https://postgr.es/m/[email protected]
M configure
M configure.in
M src/include/c.h
M src/include/pg_config.h.in
M src/include/pg_config.h.win32
Arrange to supply declarations for strtoll/strtoull if needed.
commit : 4ffd7909c63a54960c90dc3332b591d075c48e46
author : Tom Lane <[email protected]>
date : Fri, 18 May 2018 22:42:10 -0400
committer: Tom Lane <[email protected]>
date : Fri, 18 May 2018 22:42:10 -0400
Buildfarm member dromedary is still unhappy about the recently-added
ecpg "long long" tests. The reason turns out to be that it includes
"-ansi" in its CFLAGS, and in their infinite wisdom Apple have decided
to hide the declarations of strtoll/strtoull in C89-compliant builds.
(I find it pretty curious that they hide those function declarations
when you can nonetheless declare a "long long" variable, but anyway
that is their behavior, both on dromedary's obsolete macOS version and
the newest and shiniest.) As a result, gcc assumes these functions
return "int", leading naturally to wrong results.
(Looking at dromedary's past build results, it's evident that this
problem also breaks pg_strtouint64() on 32-bit platforms; but we
evidently have no regression tests that exercise that function with
values above 32 bits.)
To fix, supply declarations for these functions when the platform
provides the functions but not the declarations, using the same type
of mechanism as we use for some other similar cases.
Discussion: https://postgr.es/m/[email protected]
M configure
M configure.in
M src/include/c.h
M src/include/pg_config.h.in
M src/include/pg_config.h.win32
Hot-fix ecpg regression test for missing ecpg_config.h inclusion.
commit : 4ca492425cd99efc6827c265d4d5a60f65971ae9
author : Tom Lane <[email protected]>
date : Fri, 18 May 2018 19:03:32 -0400
committer: Tom Lane <[email protected]>
date : Fri, 18 May 2018 19:03:32 -0400
I don't think this is really the best long-term answer, and in
particular it doesn't fix the pre-existing hazard in sqltypes.h.
But for the moment let's just try to make the buildfarm green again.
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/sql/sqlda.pgc
Add some test coverage for ecpg's "long long" support.
commit : ec99e9aa110ab52fffa9053f504eeb42cfd493d2
author : Tom Lane <[email protected]>
date : Fri, 18 May 2018 13:04:59 -0400
committer: Tom Lane <[email protected]>
date : Fri, 18 May 2018 13:04:59 -0400
This will only actually exercise the "long long" code paths on platforms
where "long" is 32 bits --- otherwise, the SQL bigint type maps to
plain "long", and we will test that code path instead. But that's
probably sufficient coverage, and anyway we weren't testing either
code path before.
Dang Minh Huong, tweaked a bit by me
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/expected/sql-sqlda.stderr
M src/interfaces/ecpg/test/expected/sql-sqlda.stdout
M src/interfaces/ecpg/test/sql/sqlda.pgc
Recognize that MSVC can support strtoll() and strtoull().
commit : 25caeae8d2797ef70c3991b295039159c2a1be21
author : Tom Lane <[email protected]>
date : Fri, 18 May 2018 12:52:28 -0400
committer: Tom Lane <[email protected]>
date : Fri, 18 May 2018 12:52:28 -0400
This is needed for full support of "long long" variables in ecpg, but
the previous patch for bug #15080 (commits 51057feaa et al) missed it.
In MSVC versions where the functions don't exist under those names,
we can nonetheless use _strtoi64() and _strtoui64().
Like the previous patch, back-patch all the way.
Dang Minh Huong
Discussion: https://postgr.es/m/[email protected]
M src/include/pg_config.h.win32
Fix error message on short read of pg_control
commit : 830e8e3609d003e320b963a7fa7c1432e10d8766
author : Magnus Hagander <[email protected]>
date : Fri, 18 May 2018 17:53:15 +0200
committer: Magnus Hagander <[email protected]>
date : Fri, 18 May 2018 17:53:15 +0200
Instead of saying "error: success", indicate that we got a working read
but it was too short.
M src/backend/access/transam/xlog.c
M src/common/controldata_utils.c
doc: fix description of backward_scan
commit : 4a9b44d3c075fe73661d0407faf6f048075a00f9
author : Andrew Gierth <[email protected]>
date : Thu, 17 May 2018 21:19:57 +0100
committer: Andrew Gierth <[email protected]>
date : Thu, 17 May 2018 21:19:57 +0100
The description of the index property backward_scan was incorrect and
misleading; rectify.
Backpatch to 9.6 where the amutils functionality was introduced.
M doc/src/sgml/func.sgml
Fix misprocessing of equivalence classes involving record_eq().
commit : ace3c7cc0518269733c37b37b7aebb9adec2454e
author : Tom Lane <[email protected]>
date : Wed, 16 May 2018 13:46:09 -0400
committer: Tom Lane <[email protected]>
date : Wed, 16 May 2018 13:46:09 -0400
canonicalize_ec_expression() is supposed to agree with coerce_type() as to
whether a RelabelType should be inserted to make a subexpression be valid
input for the operators of a given opclass. However, it did the wrong
thing with named-composite-type inputs to record_eq(): it put in a
RelabelType to RECORDOID, which the parser doesn't. In some cases this was
harmless because all code paths involving a particular equivalence class
did the same thing, but in other cases this would result in failing to
recognize a composite-type expression as being a member of an equivalence
class that it actually is a member of. The most obvious bad effect was to
fail to recognize that an index on a composite column could provide the
sort order needed for a mergejoin on that column, as reported by Teodor
Sigaev. I think there might be other, subtler, cases that result in
misoptimization. It also seems possible that an unwanted RelabelType
would sometimes get into an emitted plan --- but because record_eq and
friends don't examine the declared type of their input expressions, that
would not create any visible problems.
To fix, just treat RECORDOID as if it were a polymorphic type, which in
some sense it is. We might want to consider formalizing that a bit more
someday, but for the moment this seems to be the only place where an
IsPolymorphicType() test ought to include RECORDOID as well.
This has been broken for a long time, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/path/equivclass.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix type checking for support functions of parallel VARIADIC aggregates.
commit : f92491186b6fd5c4f5b90738d385d7d17f95e338
author : Tom Lane <[email protected]>
date : Tue, 15 May 2018 15:06:53 -0400
committer: Tom Lane <[email protected]>
date : Tue, 15 May 2018 15:06:53 -0400
The impact of VARIADIC on the combine/serialize/deserialize support
functions of an aggregate wasn't thought through carefully. There is
actually no impact, because variadicity isn't passed through to these
functions (and it doesn't seem like it would need to be). However,
lookup_agg_function was mistakenly told to check things as though it were
passed through. The net result was that it was impossible to declare an
aggregate that had both VARIADIC input and parallelism support functions.
In passing, fix a runtime check in nodeAgg.c for the combine function's
strictness to make its error message agree with the creation-time check.
The previous message was actually backwards, and it doesn't seem like
there's a good reason to have two versions of this message text anyway.
Back-patch to 9.6 where parallel aggregation was introduced.
Alexey Bashtanov; message fix by me
Discussion: https://postgr.es/m/[email protected]
M src/backend/catalog/pg_aggregate.c
M src/backend/executor/nodeAgg.c
Update time zone data files to tzdata release 2018e.
commit : 22e524d97774e71bb56c5aa613342e961056f50b
author : Tom Lane <[email protected]>
date : Wed, 9 May 2018 13:55:27 -0400
committer: Tom Lane <[email protected]>
date : Wed, 9 May 2018 13:55:27 -0400
DST law changes in North Korea. Redefinition of "daylight savings" in
Ireland, as well as for some past years in Namibia and Czechoslovakia.
Additional historical corrections for Czechoslovakia.
With this change, the IANA database models Irish timekeeping as following
"standard time" in summer, and "daylight savings" in winter, so that the
daylight savings offset is one hour behind standard time not one hour
ahead. This does not change their UTC offset (+1:00 in summer, 0:00 in
winter) nor their timezone abbreviations (IST in summer, GMT in winter),
though now "IST" is more correctly read as "Irish Standard Time" not "Irish
Summer Time". However, the "is_dst" column in the pg_timezone_names view
will now be true in winter and false in summer for the Europe/Dublin zone.
Similar changes were made for Namibia between 1994 and 2017, and for
Czechoslovakia between 1946 and 1947.
So far as I can find, no Postgres internal logic cares about which way
tm_isdst is reported; in particular, since commit b2cbced9e we do not
rely on it to decide how to interpret ambiguous timestamps during DST
transitions. So I don't think this change will affect any Postgres
behavior other than the timezone-view outputs.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/datetime.c
M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Europe.txt
Improve inefficient regexes in vacuumdb TAP test.
commit : 36784e9147face9624663d8165e008b46d31b3bc
author : Tom Lane <[email protected]>
date : Tue, 8 May 2018 20:17:43 -0400
committer: Tom Lane <[email protected]>
date : Tue, 8 May 2018 20:17:43 -0400
The regexes used in 102_vacuumdb_stages.pl to check the postmaster log
for expected output contained several places with ".*.*", which is
underdetermined and can cause exponential runtime growth in Perl's regex
matcher (since it's not bright enough not to waste time seeing whether
different splits of the same substring would allow a match). We were
fortunate that the amount of text in the postmaster log was generally not
enough to make the runtime go to the moon; although commit 6271fceb8 had
been on the hairy edge of an obvious problem, thanks to its increasing the
default log verbosity to DEBUG1. Experimentation shows that anyone who
tried to run this test case with an even higher log verbosity would have
been in for serious pain. But even at default logging level, fixing this
saves several hundred ms on my workstation, more on slower buildfarm
members.
Remove the extra ".*"s, restoring more-or-less-linear matching speed.
Back-patch to 9.4 where the test case was added, mostly in case anyone
tries to do related debugging in a back branch.
Discussion: https://postgr.es/m/[email protected]
M src/bin/scripts/t/102_vacuumdb_stages.pl