Stamp 9.6.16.
commit : 39b3a8c830097af84f655a36879eb1b686fb4cd7
author : Tom Lane <[email protected]>
date : Mon, 11 Nov 2019 17:09:28 -0500
committer: Tom Lane <[email protected]>
date : Mon, 11 Nov 2019 17:09:28 -0500
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
Doc: fix ancient mistake, or at least obsolete info, in rules example.
commit : 750d72fde6233b4ccad5f5416b68042169c97b61
author : Tom Lane <[email protected]>
date : Mon, 11 Nov 2019 14:39:55 -0500
committer: Tom Lane <[email protected]>
date : Mon, 11 Nov 2019 14:39:55 -0500
The example of expansion of multiple views claimed that the resulting
subquery nest would not get fully flattened because of an aggregate
function. There's no aggregate in the example, though, only a user
defined function confusingly named MIN(). In a modern server, the
reason for the non-flattening is that MIN() is volatile, but I'm
unsure whether that was true back when this text was written.
Let's reduce the confusion level by using LEAST() instead (which
we didn't have at the time this example was created). And then
we can just say that the planner will flatten the sub-queries, so
the rewrite system doesn't have to.
Noted by Paul Jungwirth. This text is old enough to vote, so
back-patch to all supported branches.
Discussion: https://postgr.es/m/CA+renyXZFnmp9PcvX1EVR2dR=XG5e6E-AELr8AHCNZ8RYrpnPw@mail.gmail.com
M doc/src/sgml/rules.sgml
Translation updates
commit : 286bbad9f4bd69c99d717ddb9a30a4a9135f3d63
author : Peter Eisentraut <[email protected]>
date : Mon, 11 Nov 2019 10:27:46 +0100
committer: Peter Eisentraut <[email protected]>
date : Mon, 11 Nov 2019 10:27:46 +0100
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 9ed174ac417451d7c78d72731c7d85e37ac06d90
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/backend/po/tr.po
M src/bin/initdb/po/cs.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/ru.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_config/po/es.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_controldata/po/cs.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/es.po
M src/bin/pg_rewind/nls.mk
M src/bin/pg_rewind/po/cs.po
M src/bin/pg_rewind/po/es.po
M src/bin/pg_rewind/po/ja.po
M src/bin/pg_rewind/po/ru.po
M src/bin/psql/po/de.po
M src/bin/psql/po/es.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/cs.po
M src/bin/scripts/po/de.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/ru.po
M src/bin/scripts/po/sv.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/ru.po
Release notes for 12.1, 11.6, 10.11, 9.6.16, 9.5.20, 9.4.25.
commit : 00c5d7e2c8e9027f3f2f505dd93c6bd79bdd336f
author : Tom Lane <[email protected]>
date : Sun, 10 Nov 2019 18:31:13 -0500
committer: Tom Lane <[email protected]>
date : Sun, 10 Nov 2019 18:31:13 -0500
M doc/src/sgml/release-9.6.sgml
Remove test case that doesn't work with --disable-integer-timestamps.
commit : a55018760dcf24e560c36dfb53b9a8b0bd5e6829
author : Tom Lane <[email protected]>
date : Sat, 9 Nov 2019 15:50:16 -0500
committer: Tom Lane <[email protected]>
date : Sat, 9 Nov 2019 15:50:16 -0500
Commits a7145f6bc et al. added a test to verify integer overflow
detection in interval_mul. That only applies with integer timestamps,
of course, so it's problematic in pre-v10 branches where we supported
float timestamps. The test was only marginally worth the trouble to
begin with, so just remove it in those branches. Per buildfarm.
Discussion: https://postgr.es/m/[email protected]
M src/test/regress/expected/interval.out
M src/test/regress/sql/interval.sql
Fix gratuitous error message variation
commit : a9c3cda2816ffef76a6f49cc7ba14233e8d9cad1
author : Peter Eisentraut <[email protected]>
date : Fri, 8 Nov 2019 18:12:51 +0100
committer: Peter Eisentraut <[email protected]>
date : Fri, 8 Nov 2019 18:12:51 +0100
M src/backend/replication/logical/origin.c
postgres_fdw: Fix error message for PREPARE TRANSACTION.
commit : bca0aed2d01ce50e2f7be14c97f80118b0f67952
author : Etsuro Fujita <[email protected]>
date : Fri, 8 Nov 2019 17:00:35 +0900
committer: Etsuro Fujita <[email protected]>
date : Fri, 8 Nov 2019 17:00:35 +0900
Currently, postgres_fdw does not support preparing a remote transaction
for two-phase commit even in the case where the remote transaction is
read-only, but the old error message appeared to imply that that was not
supported only if the remote transaction modified remote tables. Change
the message so as to include the case where the remote transaction is
read-only.
Also fix a comment above the message.
Also add a note about the lack of supporting PREPARE TRANSACTION to the
postgres_fdw documentation.
Reported-by: Gilles Darold
Author: Gilles Darold and Etsuro Fujita
Reviewed-by: Michael Paquier and Kyotaro Horiguchi
Backpatch-through: 9.4
Discussion: https://postgr.es/m/08600ed3-3084-be70-65ba-279ab19618a5%40darold.net
M contrib/postgres_fdw/connection.c
M doc/src/sgml/postgres-fdw.sgml
docs: clarify that only INSERT and UPDATE triggers can mod. NEW
commit : 685d6cb8cd4c2909c94b4b7c050cd9767cda26cf
author : Bruce Momjian <[email protected]>
date : Thu, 7 Nov 2019 15:49:59 -0500
committer: Bruce Momjian <[email protected]>
date : Thu, 7 Nov 2019 15:49:59 -0500
The point is that DELETE triggers cannot modify any values.
Reported-by: Eugen Konkov
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/trigger.sgml
Move declaration of ecpg_gettext() to a saner place.
commit : baa483984fdeacd2c07a48c24a357977e048e0f8
author : Tom Lane <[email protected]>
date : Thu, 7 Nov 2019 14:21:52 -0500
committer: Tom Lane <[email protected]>
date : Thu, 7 Nov 2019 14:21:52 -0500
Declaring this in the client-visible header ecpglib.h was a pretty
poor decision. It's not meant to be application-callable (and if
it was, putting it outside the extern "C" { ... } wrapper means
that C++ clients would fail to call it). And the declaration would
not even compile for a client, anyway, since it would not have the
macro pg_attribute_format_arg(). Fortunately, it seems that no
clients have tried to include this header with ENABLE_NLS defined,
or we'd have gotten complaints about that. But we have no business
putting such a restriction on client code.
Move the declaration to ecpglib_extern.h, since in fact nothing
outside src/interfaces/ecpg/ecpglib/ needs to call it.
The practical effect of this is just that clients can now safely
#include ecpglib.h while having ENABLE_NLS defined, but that seems
like enough of a reason to back-patch it.
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/ecpg/ecpglib/extern.h
M src/interfaces/ecpg/include/ecpglib.h
Fix integer-overflow edge case detection in interval_mul and pgbench.
commit : 15783d057543edde84b537815a8f22cf99d4beaa
author : Tom Lane <[email protected]>
date : Thu, 7 Nov 2019 11:22:52 -0500
committer: Tom Lane <[email protected]>
date : Thu, 7 Nov 2019 11:22:52 -0500
This patch adopts the overflow check logic introduced by commit cbdb8b4c0
into two more places. interval_mul() failed to notice if it computed a
new microseconds value that was one more than INT64_MAX, and pgbench's
double-to-int64 logic had the same sorts of edge-case problems that
cbdb8b4c0 fixed in the core code.
To make this easier to get right in future, put the guts of the checks
into new macros in c.h, and add commentary about how to use the macros
correctly.
Back-patch to all supported branches, as we did with the previous fix.
Yuya Watari
Discussion: https://postgr.es/m/CAJ2pMkbkkFw2hb9Qb1Zj8d06EhWAQXFLy73St4qWv6aX=vqnjw@mail.gmail.com
M src/backend/utils/adt/float.c
M src/backend/utils/adt/int8.c
M src/backend/utils/adt/timestamp.c
M src/bin/pgbench/pgbench.c
M src/include/c.h
M src/test/regress/expected/interval.out
M src/test/regress/sql/interval.sql
Fix assertion failure when running pgbench -s.
commit : aa7cd6a8e7414d4d52c44ebe246567e3c44d9df9
author : Fujii Masao <[email protected]>
date : Thu, 7 Nov 2019 16:31:36 +0900
committer: Fujii Masao <[email protected]>
date : Thu, 7 Nov 2019 16:31:36 +0900
If there is the WAL page that the continuation WAL record just fits within
(i.e., the continuation record ends just at the end of the page) and
the LSN in such page is specified with -s option, previously pg_waldump
caused an assertion failure. The cause of this assertion failure was that
XLogFindNextRecord() that pg_waldump -s calls mistakenly handled
such special WAL page.
This commit changes XLogFindNextRecord() so that it can handle
such WAL page correctly.
Back-patch to all supported versions.
Author: Andrey Lepikhov
Reviewed-by: Fujii Masao, Michael Paquier
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/xlogreader.c
Fix timestamp of sent message for write context in logical decoding
commit : 16b43e091c779cd8c34cdaeeacbe402bfb99dd5c
author : Michael Paquier <[email protected]>
date : Wed, 6 Nov 2019 16:12:47 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 6 Nov 2019 16:12:47 +0900
When sending data for logical decoding using the streaming replication
protocol via a WAL sender, the timestamp of the sent write message is
allocated at the beginning of the message when preparing for the write,
and actually computed when the write message is ready to be sent.
The timestamp was getting computed after sending the message. This
impacts anything using logical decoding, causing for example logical
replication to report mostly NULL for last_msg_send_time in
pg_stat_subscription.
This commit makes sure that the timestamp is computed before sending the
message. This is wrong since 5a991ef, so backpatch down to 9.4.
Author: Jeff Janes
Discussion: https://postgr.es/m/CAMkU=1z=WMn8jt7iEdC5sYNaPgAgOASb_OW5JYv-vMdYaJSL-w@mail.gmail.com
Backpatch-through: 9.4
M src/backend/replication/walsender.c
Request small targetlist for input to WindowAgg.
commit : 747aac88fa5377586fb2fdbd261f1d5fb7a50308
author : Andrew Gierth <[email protected]>
date : Wed, 6 Nov 2019 04:13:30 +0000
committer: Andrew Gierth <[email protected]>
date : Wed, 6 Nov 2019 04:13:30 +0000
WindowAgg will potentially store large numbers of input rows into
tuplestores to allow access to other rows in the frame. If the input
is coming via an explicit Sort node, then unneeded columns will
already have been discarded (since Sort requests a small tlist); but
there are idioms like COUNT(*) OVER () that result in the input not
being sorted at all, and cases where the input is being sorted by some
means other than a Sort; if we don't request a small tlist, then
WindowAgg's storage requirement is inflated by the unneeded columns.
Backpatch back to 9.6, where the current tlist handling was added.
(Prior to that, WindowAgg would always use a small tlist.)
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/plan/createplan.c
doc: fix plurality typo on bgwriter doc sentence
commit : 1673a667d4323f056e4cef715cf4c162190ce8e0
author : Bruce Momjian <[email protected]>
date : Tue, 5 Nov 2019 20:54:04 -0500
committer: Bruce Momjian <[email protected]>
date : Tue, 5 Nov 2019 20:54:04 -0500
Reported-by: [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/bgworker.sgml
Avoid logging complaints about abandoned connections when using PAM.
commit : 383602f9abaeeb5315d4a4f0c620d64843ee7f51
author : Tom Lane <[email protected]>
date : Tue, 5 Nov 2019 14:27:37 -0500
committer: Tom Lane <[email protected]>
date : Tue, 5 Nov 2019 14:27:37 -0500
For a long time (since commit aed378e8d) we have had a policy to log
nothing about a connection if the client disconnects when challenged
for a password. This is because libpq-using clients will typically
do that, and then come back for a new connection attempt once they've
collected a password from their user, so that logging the abandoned
connection attempt will just result in log spam. However, this did
not work well for PAM authentication: the bottom-level function
pam_passwd_conv_proc() was on board with it, but we logged messages
at higher levels anyway, for lack of any reporting mechanism.
Add a flag and tweak the logic so that the case is silent, as it is
for other password-using auth mechanisms.
Per complaint from Yoann La Cancellera. It's been like this for awhile,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/CACP=ajbrFFYUrLyJBLV8=q+eNCapa1xDEyvXhMoYrNphs-xqPw@mail.gmail.com
M src/backend/libpq/auth.c
Change pg_restore -f- to dump to stdout instead of to ./-
commit : 12a51e2ebea7c90eb5a676f761f81f0ec7f68a50
author : Alvaro Herrera <[email protected]>
date : Mon, 4 Nov 2019 15:50:57 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 4 Nov 2019 15:50:57 -0300
Starting with PostgreSQL 12, pg_restore refuses to run when neither -d
nor -f are specified (c.f. commit 413ccaa74d9a), and it also makes "-f -"
mean the old implicit behavior of dumping to stdout. However, older
branches write to a file called ./- when invoked like that, making it
impossible to write pg_restore scripts that work across versions. This
is a partial backpatch of the aforementioned commit to all older
supported branches, providing an upgrade path.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/pg_restore.sgml
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_restore.c
Stabilize pg_dump output order for similarly-named triggers and policies.
commit : 648f17879e61e9faa007eab56331afe77b696c1e
author : Tom Lane <[email protected]>
date : Mon, 4 Nov 2019 16:25:05 -0500
committer: Tom Lane <[email protected]>
date : Mon, 4 Nov 2019 16:25:05 -0500
The code only compared two triggers' names and namespaces (the latter
being the owning table's schema). This could result in falling back
to an OID-based sort of similarly-named triggers on different tables.
We prefer to avoid that, so add a comparison of the table names too.
(The sort order is thus table namespace, trigger name, table name,
which is a bit odd, but it doesn't seem worth contorting the code
to work around that.)
Likewise for policy objects, in 9.5 and up.
Complaint and fix by Benjie Gillam. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/CAMThMzEEt2mvBbPgCaZ1Ap1N-moGn=Edxmadddjq89WG4NpPtQ@mail.gmail.com
M src/bin/pg_dump/pg_dump_sort.c
Catch invalid typlens in a couple of places
commit : 2dbe5706bb9485d7293798e8f80e9d9ba78fbfdc
author : Peter Eisentraut <[email protected]>
date : Mon, 4 Nov 2019 09:54:47 +0100
committer: Peter Eisentraut <[email protected]>
date : Mon, 4 Nov 2019 09:54:47 +0100
Rearrange the logic in record_image_cmp() and record_image_eq() to
error out on unexpected typlens (either not supported there or
completely invalid due to corruption). Barring corruption, this is
not possible today but it seems more future-proof and robust to fix
this.
Reported-by: Peter Geoghegan <[email protected]>
M src/backend/utils/adt/rowtypes.c
Suppress warning from older compilers.
commit : d43bd9dce854ff8c2a088999dd860b05d19ebc5a
author : Tom Lane <[email protected]>
date : Sun, 3 Nov 2019 16:10:23 -0500
committer: Tom Lane <[email protected]>
date : Sun, 3 Nov 2019 16:10:23 -0500
Commit 8af1624e3 introduced a warning about possibly returning
without a value, on compilers that don't realize that ereport(ERROR)
doesn't return. Tweak the code to avoid that.
Per buildfarm. Back-patch to 9.6, like the aforesaid commit.
M src/backend/tsearch/spell.c
Validate ispell dictionaries more carefully.
commit : 51b9ac5588bcb350bd9433307ee6a6236b01039b
author : Tom Lane <[email protected]>
date : Sat, 2 Nov 2019 16:45:32 -0400
committer: Tom Lane <[email protected]>
date : Sat, 2 Nov 2019 16:45:32 -0400
Using incorrect, or just mismatched, dictionary and affix files
could result in a crash, due to failure to cross-check offsets
obtained from the file. Add necessary validation, as well as
some Asserts for future-proofing.
Per bug #16050 from Alexander Lakhin. Back-patch to 9.6 where the
problem was introduced.
Arthur Zakirov, per initial investigation by Tomas Vondra
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/20191013012610.2p2fp3zzpoav7jzf@development
M src/backend/tsearch/spell.c
M src/test/regress/expected/tsdicts.out
M src/test/regress/sql/tsdicts.sql
Fix race condition at backend exit when deleting element in syncrep queue
commit : 52684bc7d9579fefa69e09797e798dbe2b0acbd2
author : Michael Paquier <[email protected]>
date : Fri, 1 Nov 2019 22:39:01 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 1 Nov 2019 22:39:01 +0900
When a backend exits, it gets deleted from the syncrep queue if present.
The queue was checked without SyncRepLock taken in exclusive mode, so it
would have been possible for a backend to remove itself after a WAL
sender already did the job. Fix this issue based on a suggestion from
Fujii Masao, by first checking the queue without the lock. Then, if the
backend is present in the queue, take the lock and perform an additional
lookup check before doing the element deletion.
Author: Dongming Liu
Reviewed-by: Kyotaro Horiguchi, Fujii Masao, Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M src/backend/replication/syncrep.c
pg_waldump: Fix --bkp-details to not issue spurious newlines for FPWs.
commit : bc4f56c181aede01715f3a44232ce3e373fc8cfb
author : Andres Freund <[email protected]>
date : Tue, 29 Oct 2019 22:46:40 -0700
committer: Andres Freund <[email protected]>
date : Tue, 29 Oct 2019 22:46:40 -0700
The additional newline seems to have accidentally been introduced in
2c03216d831, in 9.5. The newline is only issued when an FPW is
present for the block reference.
While there could be an argument that removing the newlines in the
back branches could cause a problem for somebody parsing the
pg_waldump output, the likelihood of that seems small enough. It seems
at least equally likely that the randomness of when newlines are
issued causes problems.
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch: 9.5, like 2c03216d831.
M src/bin/pg_xlogdump/pg_xlogdump.c
pg_waldump: Fix small memory leak when rmgr->rm_identify returns NULL.
commit : 95f2efd5041b95cb92e3940e79cbbb65c4c4b09e
author : Andres Freund <[email protected]>
date : Tue, 29 Oct 2019 19:18:07 -0700
committer: Andres Freund <[email protected]>
date : Tue, 29 Oct 2019 19:18:07 -0700
This got broken in 604f7956b94, shortly after rm_identify's
introduction.
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch: 9.5, where rm_identify was introduced
M src/bin/pg_xlogdump/pg_xlogdump.c
Fix pg_dump's handling of circular dependencies in views.
commit : 404cbc5620f4d0cec213d8804f612776dc302d55
author : Tom Lane <[email protected]>
date : Sat, 26 Oct 2019 17:37:19 -0400
committer: Tom Lane <[email protected]>
date : Sat, 26 Oct 2019 17:37:19 -0400
This is a back-patch of the v10 commit d8c05aff5. The motivation for
doing this now is that we received a complaint that a view with a
circular dependency is dumped with an extra bogus command "ALTER TABLE
ONLY myview REPLICA IDENTITY NOTHING", because pg_dump forgets that it's
a view not a table, and the relreplident value stored for a view is that.
So you'll get an error message during restore even if not using --clean;
this would break pg_upgrade for example. While that could be handled
with a one-line patch, it seems better to back-patch d8c05aff5, since that
produces cleaner more future-proof output and fixes an additional bug.
Per gripe from Alex Williams. Back-patch to 9.4-9.6 (even if 9.3 were
still in support, it hasn't got REPLICA IDENTITY so no bug).
Discussion: https://postgr.es/m/NFqxoEi7-8Rw9OW0f-GwHcjvS2I4YQXov4g9OoWv3i7lVOZdLWkAWl9jQQqwEaUq6WV0vdobromhW82e8y5I0_59yZTXcZnXsrmFuldlmZc=@protonmail.com
Original commit message follows:
pg_dump's traditional solution for breaking a circular dependency involving
a view was to create the view with CREATE TABLE and then later issue CREATE
RULE "_RETURN" ... to convert the table to a view, relying on the backend's
very very ancient code that supports making views that way. We've wanted
to get rid of that kluge for a long time, but the thing that finally
motivates doing something about it is the recognition that this method
fails with the --clean option, because it leads to issuing DROP RULE
"_RETURN" followed by DROP TABLE --- and the backend won't let you drop a
view's _RETURN rule.
Instead, let's break circular dependencies by initially creating the view
using CREATE VIEW AS SELECT NULL::columntype AS columnname, ... (so that
it has the right column names and types to support external references,
but no dependencies beyond the column data types), and then later dumping
the ON SELECT rule using the spelling CREATE OR REPLACE VIEW. This method
wasn't available when this code was originally written, but it's been
possible since PG 7.3, so it seems fine to start relying on it now.
To solve the --clean problem, make the dropStmt for an ON SELECT rule
be CREATE OR REPLACE VIEW with the same dummy target list as above.
In this way, during the DROP phase, we first reduce the view to have
no extra dependencies, and then we can drop it entirely when we've
gotten rid of whatever had a circular dependency on it.
(Note: this should work adequately well with the --if-exists option, since
the CREATE OR REPLACE VIEW will go through whether the view exists or not.
It could fail if the view exists with a conflicting column set, but we
don't really support --clean against a non-matching database anyway.)
This allows cleaning up some other kluges inside pg_dump, notably that
we don't need a notion of reloptions attached to a rule anymore.
Although this is a bug fix, commit to HEAD only for now. The problem's
existed for a long time and we've had relatively few complaints, so it
doesn't really seem worth taking risks to fix it in the back branches.
We might revisit that choice if no problems emerge.
Discussion: <[email protected]>
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/pg_dump/pg_dump_sort.c
docs: fix wording of REFRESH CONCURRENTLY manual page
commit : 9a573e1fd49faf42be4381216dd007e8270c7b6d
author : Bruce Momjian <[email protected]>
date : Wed, 23 Oct 2019 20:29:02 -0400
committer: Bruce Momjian <[email protected]>
date : Wed, 23 Oct 2019 20:29:02 -0400
Reported-by: Asim / [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/ref/refresh_materialized_view.sgml
Clean up properly error_context_stack in autovacuum worker on exception
commit : 56820c714a3997163e73ba65396c2481be505c18
author : Michael Paquier <[email protected]>
date : Wed, 23 Oct 2019 10:26:16 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 23 Oct 2019 10:26:16 +0900
Any callback set would have no meaning in the context of an exception.
As an autovacuum worker exits quickly in this context, this could be
only an issue within EmitErrorReport(), where the elog hook is for
example called. That's unlikely to going to be a problem, but let's be
clean and consistent with other code paths handling exceptions. This is
present since 2909419, which introduced autovacuum.
Author: Ashwin Agrawal
Reviewed-by: Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/CALfoeisM+_+dgmAdAOHAu0k-ZpEHHqSSG=GRf3pKJGm8OqWX0w@mail.gmail.com
Backpatch-through: 9.4
M src/backend/postmaster/autovacuum.c
Deal with yet another issue related to "Norwegian (Bokmål)" locale.
commit : 185253ab847b95c793e3bae861611ae07a06d7c4
author : Tom Lane <[email protected]>
date : Mon, 21 Oct 2019 14:18:01 -0400
committer: Tom Lane <[email protected]>
date : Mon, 21 Oct 2019 14:18:01 -0400
It emerges that recent versions of Windows (at least 2016 Standard)
spell this locale name as "Norwegian Bokmål_Norway.1252", defeating
our mapping code that translates "Norwegian (Bokmål)_Norway" to
something that's all-ASCII (cf commits db29620d4 and aa1d2fc5e).
Add another mapping entry to handle this spelling.
Per bug #16068 from Robert Ford. Like the previous patches,
back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/port/win32setlocale.c
Use CFLAGS_SL while probing linkability of libperl.
commit : 34621cb12098d28010d8360b7e342739ef6de625
author : Tom Lane <[email protected]>
date : Mon, 21 Oct 2019 13:52:25 -0400
committer: Tom Lane <[email protected]>
date : Mon, 21 Oct 2019 13:52:25 -0400
On recent Red Hat platforms (at least RHEL 8 and Fedora 30, maybe older),
configure's probe for libperl failed if the user forces CFLAGS to be -O0.
This is because some code in perl's inline.h fails to be optimized away
at -O0, and said code doesn't work if compiled without -fPIC.
To fix, add CFLAGS_SL to the compile flags used during the libperl probe.
This is a better simulation of the way that plperl is built, anyway,
so it might forestall other issues in future.
Per gripe from Kyotaro Horiguchi. Back-patch to all supported branches,
since people might want to build older branches on these platforms.
Discussion: https://postgr.es/m/[email protected]
M configure
M configure.in
Select CFLAGS_SL at configure time, not in platform-specific Makefiles.
commit : 62ca50ad7ad05fbbc053a4e3687a6e4edb711049
author : Tom Lane <[email protected]>
date : Mon, 21 Oct 2019 12:32:36 -0400
committer: Tom Lane <[email protected]>
date : Mon, 21 Oct 2019 12:32:36 -0400
Move the platform-dependent logic that sets CFLAGS_SL from
src/makefiles/Makefile.foo to src/template/foo, so that the value
is determined at configure time and thus is available while running
configure's tests.
On a couple of platforms this might save a few microseconds of build
time by eliminating a test that make otherwise has to do over and over.
Otherwise it's pretty much a wash for build purposes; in particular,
this makes no difference to anyone who might be overriding CFLAGS_SL
via a make option.
This patch in itself does nothing with the value and thus should not
change any behavior, though you'll probably have to re-run configure
to get a correctly updated Makefile.global. We'll use the new
configure variable in a follow-on patch.
Per gripe from Kyotaro Horiguchi. Back-patch to all supported branches,
because the follow-on patch is a portability bug fix.
Discussion: https://postgr.es/m/[email protected]
M configure
M configure.in
M src/Makefile.global.in
M src/makefiles/Makefile.cygwin
M src/makefiles/Makefile.freebsd
M src/makefiles/Makefile.hpux
M src/makefiles/Makefile.linux
M src/makefiles/Makefile.netbsd
M src/makefiles/Makefile.openbsd
M src/makefiles/Makefile.sco
M src/makefiles/Makefile.solaris
M src/makefiles/Makefile.unixware
M src/makefiles/Makefile.win32
M src/template/aix
M src/template/cygwin
M src/template/darwin
M src/template/freebsd
M src/template/hpux
M src/template/linux
M src/template/netbsd
M src/template/openbsd
M src/template/sco
M src/template/solaris
M src/template/unixware
M src/template/win32
For PowerPC instruction "addi", use constraint "b".
commit : 09d74aef33decd311128e65fee2b1abd94f2bc6a
author : Noah Misch <[email protected]>
date : Fri, 18 Oct 2019 20:20:28 -0700
committer: Noah Misch <[email protected]>
date : Fri, 18 Oct 2019 20:20:28 -0700
Without "b", a variant of the tas() code miscompiles on macOS 10.4.
This may also fix a compilation failure involving macOS 10.1. Today's
compilers have been allocating acceptable registers with or without this
change, but this future-proofs the code by precisely conveying the
acceptable registers. Back-patch to 9.4 (all supported versions).
Reviewed by Tom Lane.
Discussion: https://postgr.es/m/[email protected]
M src/include/storage/s_lock.h
Fix failure of archive recovery with recovery_min_apply_delay enabled.
commit : 579996bc2fc72b5496ccabe573bce8f2355c92df
author : Fujii Masao <[email protected]>
date : Fri, 18 Oct 2019 22:32:18 +0900
committer: Fujii Masao <[email protected]>
date : Fri, 18 Oct 2019 22:32:18 +0900
recovery_min_apply_delay parameter is intended for use with streaming
replication deployments. However, the document clearly explains that
the parameter will be honored in all cases if it's specified. So it should
take effect even if in archive recovery. But, previously, archive recovery
with recovery_min_apply_delay enabled always failed, and caused assertion
failure if --enable-caasert is enabled.
The cause of this problem is that; the ownership of recoveryWakeupLatch
that recovery_min_apply_delay uses was taken only when standby mode
is requested. So unowned latch could be used in archive recovery, and
which caused the failure.
This commit changes recovery code so that the ownership of
recoveryWakeupLatch is taken even in archive recovery. Which prevents
archive recovery with recovery_min_apply_delay from failing.
Back-patch to v9.4 where recovery_min_apply_delay was added.
Author: Fujii Masao
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CAHGQGwEyD6HdZLfdWc+95g=VQFPR4zQL4n+yHxQgGEGjaSVheQ@mail.gmail.com
M src/backend/access/transam/xlog.c
Fix minor bug in logical-replication walsender shutdown
commit : 5f038991ecf9ad895c6f1f3a33879da3471d1f90
author : Alvaro Herrera <[email protected]>
date : Thu, 17 Oct 2019 15:06:05 +0200
committer: Alvaro Herrera <[email protected]>
date : Thu, 17 Oct 2019 15:06:05 +0200
Logical walsender should exit when it catches up with sending WAL during
shutdown; but there was a rare corner case when it failed to because of
a race condition that puts it back to wait for more WAL instead -- but
since there wasn't any, it'd not shut down immediately. It would only
continue the shutdown when wal_sender_timeout terminates the sleep,
which causes annoying waits during shutdown procedure. Restructure the
code so that we no longer forget to set WalSndCaughtUp in that case.
This was an oversight in commit c6c333436.
Backpatch all the way down to 9.4.
Author: Craig Ringer, Álvaro Herrera
Discussion: https://postgr.es/m/CAMsr+YEuz4XwZX_QmnX_-2530XhyAmnK=zCmicEnq1vLr0aZ-g@mail.gmail.com
M src/backend/replication/walsender.c
When restoring GUCs in parallel workers, show an error context.
commit : fd5ffa425dfbc66db82980e7eb17a28c11c7fd37
author : Thomas Munro <[email protected]>
date : Thu, 17 Oct 2019 13:24:50 +1300
committer: Thomas Munro <[email protected]>
date : Thu, 17 Oct 2019 13:24:50 +1300
Otherwise it can be hard to see where an error is coming from, when
the parallel worker sets all the GUCs that it received from the
leader. Bug #15726. Back-patch to 9.5, where RestoreGUCState()
appeared.
Reported-by: Tiago Anastacio
Reviewed-by: Daniel Gustafsson, Tom Lane
Discussion: https://postgr.es/m/15726-6d67e4fa14f027b3%40postgresql.org
M src/backend/utils/misc/guc.c
Fix bug that could try to freeze running multixacts.
commit : 0640f032abe58973d254a113b19d2dec981fcf2f
author : Thomas Munro <[email protected]>
date : Thu, 17 Oct 2019 09:59:21 +1300
committer: Thomas Munro <[email protected]>
date : Thu, 17 Oct 2019 09:59:21 +1300
Commits 801c2dc7 and 801c2dc7 made it possible for vacuum to
try to freeze a multixact that is still running. That was
prevented by a check, but raised an error. Repair.
Back-patch all the way.
Author: Nathan Bossart, Jeremy Schneider
Reported-by: Jeremy Schneider
Reviewed-by: Jim Nasby, Thomas Munro
Discussion: https://postgr.es/m/DAFB8AFF-2F05-4E33-AD7F-FF8B0F760C17%40amazon.com
M src/backend/commands/vacuum.c
Add missing include to pg_upgrade/version.c
commit : e09ab32a22058f5f337533f8ac6992744b440caf
author : Tomas Vondra <[email protected]>
date : Wed, 16 Oct 2019 16:08:40 +0200
committer: Tomas Vondra <[email protected]>
date : Wed, 16 Oct 2019 16:08:40 +0200
Commit 8d48e6a724 uses RELKIND_ constants when building the query, but
did not include the header defining them. On 10+ this header is already
included, but on 9.6 and earlier it was missing. It compiles just fine,
but then fails during execution
ERROR: column "relkind_relation" does not exist
Fix by adding the necessary header file, and backpatch to 9.4-.
Backpatch-to: 9.4-
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org
M src/bin/pg_upgrade/version.c
Improve the check for pg_catalog.line data type in pg_upgrade
commit : 0a643de0871540c320a02717b202984a1a1ef5df
author : Tomas Vondra <[email protected]>
date : Wed, 16 Oct 2019 13:23:14 +0200
committer: Tomas Vondra <[email protected]>
date : Wed, 16 Oct 2019 13:23:14 +0200
The pg_upgrade check for pg_catalog.line data type when upgrading from
9.3 had a couple of issues with domains and composite types. Firstly, it
triggered false positives for composite types unused in objects with
storage. This was enough to trigger an unnecessary pg_upgrade failure:
CREATE TYPE line_composite AS (l pg_catalog.line)
On the other hand, this only happened with composite types directly on
the pg_catalog.line data type, but not with a domain. So this was not
detected
CREATE DOMAIN line_domain AS pg_catalog.line;
CREATE TYPE line_composite_2 AS (l line_domain);
unlike the first example. These false positives and inconsistencies are
unfortunate, but what's worse we've failed to detected objects using the
pg_catalog.line data type through a domain. So we missed cases like this
CREATE TABLE t (l line_composite_2);
The consequence is clusters broken after a pg_upgrade.
This fixes these false positives and false negatives by using the same
recursive CTE introduced by eaf900e842 for sql_identifier. 9.3 did not
support domains on composite types, but we can still have multi-level
composite types.
Backpatch all the way to 9.4, where the format for pg_catalog.line data
type changed.
Author: Tomas Vondra
Backpatch-to: 9.4-
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org
M src/bin/pg_upgrade/version.c
Doc: Fix various inconsistencies
commit : d87de912774a1ad7239470bd677d9a2e95c31853
author : Michael Paquier <[email protected]>
date : Wed, 16 Oct 2019 13:10:54 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 16 Oct 2019 13:10:54 +0900
This fixes multiple areas of the documentation:
- COPY for its past compatibility section.
- SET ROLE mentioning INHERITS instead of INHERIT
- PREPARE referring to stmt_name, that is not present.
- Extension documentation about format name with upgrade scripts.
Backpatch down to 9.4 for the relevant parts.
Author: Alexander Lakhin
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/extend.sgml
M doc/src/sgml/ref/copy.sgml
M doc/src/sgml/ref/set_role.sgml
AIX: Stop adding option -qsrcmsg.
commit : c73f4f680e40d8e43f9e5c9a5252094e0589b9d3
author : Noah Misch <[email protected]>
date : Sat, 12 Oct 2019 00:21:47 -0700
committer: Noah Misch <[email protected]>
date : Sat, 12 Oct 2019 00:21:47 -0700
With xlc v16.1.0, it causes internal compiler errors. With xlc versions
not exhibiting that bug, removing -qsrcmsg merely changes the compiler
error reporting format. Back-patch to 9.4 (all supported versions).
Discussion: https://postgr.es/m/[email protected]
M src/template/aix
Flush logical mapping files with fd opened for read/write at checkpoint
commit : 4e7a8874a15a9bcfe50caf7d39141796a7783507
author : Michael Paquier <[email protected]>
date : Wed, 9 Oct 2019 13:31:27 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 9 Oct 2019 13:31:27 +0900
The file descriptor was opened with read-only to fsync a regular file,
which would cause EBADFD errors on some platforms.
This is similar to the recent fix done by a586cc4b (which was broken by
me with 82a5649), except that I noticed this issue while monitoring the
backend code for similar mistakes. Backpatch to 9.4, as this has been
introduced since logical decoding exists as of b89e151.
Author: Michael Paquier
Reviewed-by: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M src/backend/access/heap/rewriteheap.c
docs: Improve A?synchronous Multimaster Replication descr.
commit : dafeac80478f8a44a96c8a3f941599317ca52391
author : Bruce Momjian <[email protected]>
date : Mon, 7 Oct 2019 18:06:07 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 7 Oct 2019 18:06:07 -0400
The docs for sync and async multimaster replication were unclear about
when to use it, and when it has benefits; this change clarifies that.
Reported-by: [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/high-availability.sgml
docs: clarify that today/tomorrow/yesterday is at 00:00
commit : 1b1339838d75dbaa2e7b74fa9ce990ef6345cf66
author : Bruce Momjian <[email protected]>
date : Mon, 7 Oct 2019 17:26:46 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 7 Oct 2019 17:26:46 -0400
This should help people clearly know that these days start at midnight.
Reported-by: David Harper
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/datatype.sgml
doc: move mention of log_min_error_statement in a better spot
commit : ef0668a51cabadf688e57e048503870fd571b899
author : Bruce Momjian <[email protected]>
date : Mon, 7 Oct 2019 14:33:31 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 7 Oct 2019 14:33:31 -0400
Previously it was mentioned in the lock_timeout docs in a confusing
location.
Reported-by: [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/config.sgml
Check for too many postmaster children before spawning a bgworker.
commit : c69e982a60fb5b67fb946300209460f35c19daf2
author : Tom Lane <[email protected]>
date : Mon, 7 Oct 2019 12:39:09 -0400
committer: Tom Lane <[email protected]>
date : Mon, 7 Oct 2019 12:39:09 -0400
The postmaster's code path for spawning a bgworker neglected to check
whether we already have the max number of live child processes. That's
a bit hard to hit, since it would necessarily be a transient condition;
but if we do, AssignPostmasterChildSlot() fails causing a postmaster
crash, as seen in a report from Bhargav Kamineni.
To fix, invoke canAcceptConnections() in the bgworker code path, as we
do in the other code paths that spawn children. Since we don't want
the same pmState tests in this case, add a child-process-type parameter
to canAcceptConnections() so that it can know what to do.
Back-patch to 9.5. In principle the same hazard exists in 9.4, but the
code is enough different that this patch wouldn't quite fix it there.
Given the tiny usage of bgworkers in that branch it doesn't seem worth
creating a variant patch for it.
Discussion: https://postgr.es/m/[email protected]
M src/backend/postmaster/postmaster.c
Report test_atomic_ops() failures consistently, via macros.
commit : 639feb92e1186e1de495d1bfdb191869cb56450a
author : Noah Misch <[email protected]>
date : Sat, 5 Oct 2019 10:05:05 -0700
committer: Noah Misch <[email protected]>
date : Sat, 5 Oct 2019 10:05:05 -0700
This prints the unexpected value in more failure cases, and it removes
forty-eight hand-maintained error messages. Back-patch to 9.5, which
introduced these tests.
Reviewed (in an earlier version) by Andres Freund.
Discussion: https://postgr.es/m/[email protected]
M src/test/regress/regress.c
Disable one more set of tests from c8841199509.
commit : 04a4c03efe3e4b0cbccb7a7e2bf0047db59cad5c
author : Andres Freund <[email protected]>
date : Sat, 5 Oct 2019 08:05:11 -0700
committer: Andres Freund <[email protected]>
date : Sat, 5 Oct 2019 08:05:11 -0700
Discussion: https://postgr.es/m/[email protected]
Backpatch: 9.6-, just like c8841199509 and 6e61d75f525
M src/test/isolation/expected/eval-plan-qual-trigger.out
M src/test/isolation/specs/eval-plan-qual-trigger.spec
Disable one set of tests from c8841199509.
commit : e25847b471e2433838deb98ebff6bf50228d9677
author : Andres Freund <[email protected]>
date : Fri, 4 Oct 2019 21:38:16 -0700
committer: Andres Freund <[email protected]>
date : Fri, 4 Oct 2019 21:38:16 -0700
One of the upsert related tests is unstable (sometimes even hanging
until isolationtester's step timeout is reached). Based on preliminary
analysis that might be a problem outside of just that test, but not
really related to EPQ and triggers. Disable for now, to get the
buildfarm greener again.
Discussion: https://postgr.es/m/[email protected]
Backpatch: 9.6-, just like c8841199509.
M src/test/isolation/expected/eval-plan-qual-trigger.out
M src/test/isolation/specs/eval-plan-qual-trigger.spec
Add isolation tests for the combination of EPQ and triggers.
commit : 04619f508fbfc7acf29d7c0aaddc2a65622b8aa0
author : Andres Freund <[email protected]>
date : Fri, 4 Oct 2019 14:01:35 -0700
committer: Andres Freund <[email protected]>
date : Fri, 4 Oct 2019 14:01:35 -0700
As evidenced by bug #16036 this area is woefully under-tested. Add
fairly extensive tests for the combination.
Backpatch back to 9.6 - before that isolationtester was not capable
enough. While we don't backpatch tests all the time, future fixes to
trigger.c would potentially look different enough in 12+ from the
earlier branches that introducing bugs during backpatching is more
likely than normal. Also, it's just a crucial and undertested area of
the code.
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch: 9.6-, the earliest these tests work
A src/test/isolation/expected/eval-plan-qual-trigger.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/eval-plan-qual-trigger.spec
Handle spaces in OpenSSL install location for MSVC
commit : 1e9a0487d6a176b1ac4770d4406aac19da16f598
author : Andrew Dunstan <[email protected]>
date : Fri, 4 Oct 2019 15:34:40 -0400
committer: Andrew Dunstan <[email protected]>
date : Fri, 4 Oct 2019 15:34:40 -0400
First, make sure that the .exe name is quoted when trying to get the
version number. Also, don't quote the lib name for using in the project
files if it's already been quoted. This second change applies to all
libraries, not just OpenSSL.
This has clearly been broken forever, so backpatch to all live branches.
M src/tools/msvc/Project.pm
M src/tools/msvc/Solution.pm
Fix bitshiftright()'s zero-padding some more.
commit : 30e5b3bbe9ca9f3594816788fe4469798da04f64
author : Tom Lane <[email protected]>
date : Fri, 4 Oct 2019 10:34:21 -0400
committer: Tom Lane <[email protected]>
date : Fri, 4 Oct 2019 10:34:21 -0400
Commit 5ac0d9360 failed to entirely fix bitshiftright's habit of
leaving one-bits in the pad space that should be all zeroes,
because in a moment of sheer brain fade I'd concluded that only
the code path used for not-a-multiple-of-8 shift distances needed
to be fixed. Of course, a multiple-of-8 shift distance can also
cause the problem, so we need to forcibly zero the extra bits
in both cases.
Per bug #16037 from Alexander Lakhin. As before, back-patch to all
supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/varbit.c
M src/test/regress/expected/bit.out
M src/test/regress/sql/bit.sql
Avoid unnecessary out-of-memory errors during encoding conversion.
commit : 677989cc0107bbd9ca09e3aea6fd60f6aa34e9cb
author : Tom Lane <[email protected]>
date : Thu, 3 Oct 2019 17:34:26 -0400
committer: Tom Lane <[email protected]>
date : Thu, 3 Oct 2019 17:34:26 -0400
Encoding conversion uses the very simplistic rule that the output
can't be more than 4X longer than the input, and palloc's a buffer
of that size. This results in failure to convert any string longer
than 1/4 GB, which is becoming an annoying limitation.
As a band-aid to improve matters, allow the allocated output buffer
size to exceed 1GB. We still insist that the final result fit into
MaxAllocSize (1GB), though. Perhaps it'd be safe to relax that
restriction, but it'd require close analysis of all callers, which
is daunting (not least because external modules might call these
functions). For the moment, this should allow a 2X to 4X improvement
in the longest string we can convert, which is a useful gain in
return for quite a simple patch.
Also, once we have successfully converted a long string, repalloc
the output down to the actual string length, returning the excess
to the malloc pool. This seems worth doing since we can usually
expect to give back several MB if we take this path at all.
This still leaves much to be desired, most notably that the assumption
that MAX_CONVERSION_GROWTH == 4 is very fragile, and yet we have no
guard code verifying that the output buffer isn't overrun. Fixing
that would require significant changes in the encoding conversion
APIs, so it'll have to wait for some other day.
The present patch seems safely back-patchable, so patch all supported
branches.
Alvaro Herrera and Tom Lane
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/mb/mbutils.c
Allow repalloc() to give back space when a large chunk is downsized.
commit : e5e4f12a5f8522d853752f7233f2f3426330927d
author : Tom Lane <[email protected]>
date : Thu, 3 Oct 2019 13:56:26 -0400
committer: Tom Lane <[email protected]>
date : Thu, 3 Oct 2019 13:56:26 -0400
Up to now, if you resized a large (>8K) palloc chunk down to a smaller
size, aset.c made no attempt to return any space to the malloc pool.
That's unpleasant if a really large allocation is resized to a
significantly smaller size. I think no such cases existed when this
code was designed, and I'm not sure whether they're common even yet,
but an upcoming fix to encoding conversion will certainly create such
cases. Therefore, fix AllocSetRealloc so that it gives realloc()
a chance to do something with the block. This doesn't noticeably
increase complexity, we mostly just have to change the order in which
the cases are considered.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/mmgr/aset.c
Selectively include window frames in expression walks/mutates.
commit : 6db0d7f35917144fcd9dfbdad8c31c37a64ca144
author : Andrew Gierth <[email protected]>
date : Thu, 3 Oct 2019 10:54:52 +0100
committer: Andrew Gierth <[email protected]>
date : Thu, 3 Oct 2019 10:54:52 +0100
query_tree_walker and query_tree_mutator were skipping the
windowClause of the query, without regard for the fact that the
startOffset and endOffset in a WindowClause node are expression trees
that need to be processed. This was an oversight in commit ec4be2ee6
from 2010 which added the expression fields; the main symptom is that
function parameters in window frame clauses don't work in inlined
functions.
Fix (as conservatively as possible since this needs to not break
existing out-of-tree callers) and add tests.
Backpatch all the way, since this has been broken since 9.0.
Per report from Alastair McKinley; fix by me with kibitzing and review
from Tom Lane.
Discussion: https://postgr.es/m/DB6PR0202MB2904E7FDDA9D81504D1E8C68E3800@DB6PR0202MB2904.eurprd02.prod.outlook.com
M src/backend/catalog/dependency.c
M src/backend/nodes/nodeFuncs.c
M src/include/nodes/nodeFuncs.h
M src/test/regress/expected/window.out
M src/test/regress/sql/window.sql
Remove temporary WAL and history files at the end of archive recovery
commit : ac1efdd080b2a26bf4f072cbd01155ba623ec401
author : Michael Paquier <[email protected]>
date : Wed, 2 Oct 2019 15:54:11 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 2 Oct 2019 15:54:11 +0900
cbc55da has reworked the order of some actions at the end of archive
recovery. Unfortunately this overlooked the fact that the startup
process needs to remove RECOVERYXLOG (for temporary WAL segment newly
recovered from archives) and RECOVERYHISTORY (for temporary history
file) at this step, leaving the files around even after recovery ended.
Backpatch to 9.5, like the previous commit.
Author: Sawada Masahiko
Reviewed-by: Fujii Masao, Michael Paquier
Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cW4Hsqj+U_R26w3Q@mail.gmail.com
Backpatch-through: 9.5
M src/backend/access/transam/xlog.c
M src/test/recovery/t/002_archiving.pl
Doc: clean up markup for jsonb_set and related functions.
commit : 69ac2c6fbb9421c30012255ce40e4d6d903e063b
author : Tom Lane <[email protected]>
date : Fri, 27 Sep 2019 11:01:37 -0400
committer: Tom Lane <[email protected]>
date : Fri, 27 Sep 2019 11:01:37 -0400
The markup for optional parameters was neither correct nor consistent.
In passing, fix a spelling mistake.
Per report from Alex Macy. Some of these mistakes are old, so
back-patch as appropriate.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/func.sgml
Fix oversight in commit 4429f6a9e3e12bb4af6e3677fbc78cd80f160252.
commit : 89c98c6ce36aac802617ad10f1618711534875a6
author : Amit Kapila <[email protected]>
date : Wed, 18 Sep 2019 09:14:26 +0530
committer: Amit Kapila <[email protected]>
date : Wed, 18 Sep 2019 09:14:26 +0530
The test name and the following test cases suggest the index created
should be hash index, but it forgot to add 'using hash' in the test case.
This in itself won't improve code coverage as there were some other tests
which were covering the corresponding code. However, it is better if the
added tests serve their actual purpose.
Reported-by: Paul A Jungwirth
Author: Paul A Jungwirth
Reviewed-by: Mahendra Singh
Backpatch-through: 9.4
Discussion: https://postgr.es/m/CA+renyV=Us-5XfMC25bNp-uWSj39XgHHmGE9Rh2cQKMegSj52g@mail.gmail.com
M src/test/regress/expected/rangetypes.out
M src/test/regress/sql/rangetypes.sql
Fix failure with lock mode used for custom relation options
commit : 98b5c37852967bd28b1f102d4ac9bd0025e7c87d
author : Michael Paquier <[email protected]>
date : Wed, 25 Sep 2019 10:08:43 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 25 Sep 2019 10:08:43 +0900
In-core relation options can use a custom lock mode since 47167b7, that
has lowered the lock available for some autovacuum parameters. However
it forgot to consider custom relation options. This causes failures
with ALTER TABLE SET when changing a custom relation option, as its lock
is not defined. The existing APIs to define a custom reloption does not
allow to define a custom lock mode, so enforce its initialization to
AccessExclusiveMode which should be safe enough in all cases. An
upcoming patch will extend the existing APIs to allow a custom lock mode
to be defined.
The problem can be reproduced with bloom indexes, so add a test there.
Reported-by: Nikolay Sharplov
Analyzed-by: Thomas Munro, Michael Paquier
Author: Michael Paquier
Reviewed-by: Kuntal Ghosh
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M contrib/bloom/expected/bloom.out
M contrib/bloom/sql/bloom.sql
M src/backend/access/common/reloptions.c
Doc: clarify handling of duplicate elements in array containment tests.
commit : 184b5fad00ace7009475221fcf12088e399f3249
author : Tom Lane <[email protected]>
date : Mon, 23 Sep 2019 12:37:04 -0400
committer: Tom Lane <[email protected]>
date : Mon, 23 Sep 2019 12:37:04 -0400
The array <@ and @> operators do not worry about duplicates: if every
member of array X matches some element of array Y, then X is contained
in Y, even if several members of X get matched to the same Y member.
This was not explicitly stated in the docs though, so improve matters.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/func.sgml
Fix failure to zero-pad the result of bitshiftright().
commit : 6ddd164aaa344d2e9a1e3e62f69b6dcdfd329501
author : Tom Lane <[email protected]>
date : Sun, 22 Sep 2019 17:46:00 -0400
committer: Tom Lane <[email protected]>
date : Sun, 22 Sep 2019 17:46:00 -0400
If the bitstring length is not a multiple of 8, we'd shift the
rightmost bits into the pad space, which must be zeroes --- bit_cmp,
for one, depends on that. This'd lead to the result failing to
compare equal to what it should compare equal to, as reported in
bug #16013 from Daryl Waycott.
This is, if memory serves, not the first such bug in the bitstring
functions. In hopes of making it the last one, do a bit more work
than minimally necessary to fix the bug:
* Add assertion checks to bit_out() and varbit_out() to complain if
they are given incorrectly-padded input. This will improve the
odds that manual testing of any new patch finds problems.
* Encapsulate the padding-related logic in macros to make it
easier to use.
Also, remove unnecessary padding logic from bit_or() and bitxor().
Somebody had already noted that we need not re-pad the result of
bit_and() since the inputs are required to be the same length,
but failed to extrapolate that to the other two.
Also, move a comment block that once was near the head of varbit.c
(but people kept putting other stuff in front of it), to put it in
the header block.
Note for the release notes: if anyone has inconsistent data as a
result of saving the output of bitshiftright() in a table, it's
possible to fix it with something like
UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol);
This has been broken since day one, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/varbit.c
M src/include/utils/varbit.h
M src/test/regress/expected/bit.out
M src/test/regress/sql/bit.sql
Update time zone data files to tzdata release 2019c.
commit : 0bd64398ea28d883f44d4c2d8f689ff441af9949
author : Tom Lane <[email protected]>
date : Fri, 20 Sep 2019 19:53:33 -0400
committer: Tom Lane <[email protected]>
date : Fri, 20 Sep 2019 19:53:33 -0400
DST law changes in Fiji and Norfolk Island. Historical corrections
for Alberta, Austria, Belgium, British Columbia, Cambodia, Hong Kong,
Indiana (Perry County), Kaliningrad, Kentucky, Michigan, Norfolk
Island, South Korea, and Turkey.
M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt
Fix typo in commit 82fa3ff8672.
commit : bad51c723e8f342883e047b3845fa177a48111d1
author : Amit Kapila <[email protected]>
date : Fri, 20 Sep 2019 08:05:54 +0530
committer: Amit Kapila <[email protected]>
date : Fri, 20 Sep 2019 08:05:54 +0530
Reported-By: Kuntal Ghosh (off-list)
Backpatch-through: 9.4, like 82fa3ff8672
M doc/src/sgml/maintenance.sgml
Fix oversight in backpatch of 6cae9d2c10
commit : 140b7b1f93dcd681bf95fef4e3d9b71289c9af87
author : Alexander Korotkov <[email protected]>
date : Thu, 19 Sep 2019 23:36:01 +0300
committer: Alexander Korotkov <[email protected]>
date : Thu, 19 Sep 2019 23:36:01 +0300
During backpatch of 6cae9d2c10 Float8GetDatum() was accidentally removed. This
commit turns it back.
Reported-by: Erik Rijkers
Discussion: https://postgr.es/m/6d51305e1159241cabee132f7efc7eff%40xs4all.nl
Author: Tom Lane
Backpatch-through: from 11 to 9.5
M src/backend/access/gist/gistget.c
Improve handling of NULLs in KNN-GiST and KNN-SP-GiST
commit : 53d9cf2db5ded873fbcc031acb584a2c05e4983b
author : Alexander Korotkov <[email protected]>
date : Thu, 19 Sep 2019 21:30:19 +0300
committer: Alexander Korotkov <[email protected]>
date : Thu, 19 Sep 2019 21:30:19 +0300
This commit improves subject in two ways:
* It removes ugliness of 02f90879e7, which stores distance values and null
flags in two separate arrays after GISTSearchItem struct. Instead we pack
both distance value and null flag in IndexOrderByDistance struct. Alignment
overhead should be negligible, because we typically deal with at most few
"col op const" expressions in ORDER BY clause.
* It fixes handling of "col op NULL" expression in KNN-SP-GiST. Now, these
expression are not passed to support functions, which can't deal with them.
Instead, NULL result is implicitly assumed. It future we may decide to
teach support functions to deal with NULL arguments, but current solution is
bugfix suitable for backpatch.
Reported-by: Nikita Glukhov
Discussion: https://postgr.es/m/826f57ee-afc7-8977-c44c-6111d18b02ec%40postgrespro.ru
Author: Nikita Glukhov
Reviewed-by: Alexander Korotkov
Backpatch-through: 9.4
M src/backend/access/gist/gistget.c
M src/backend/access/gist/gistscan.c
M src/include/access/genam.h
M src/include/access/gist_private.h
M src/tools/pgindent/typedefs.list
Doc: Fix incorrect mention to connection_object in CONNECT command of ECPG
commit : 4a3d5708115a026e3f58ff3b77096f3e3c22ffa3
author : Michael Paquier <[email protected]>
date : Thu, 19 Sep 2019 13:19:14 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 19 Sep 2019 13:19:14 +0900
This fixes an inconsistency with this parameter name not listed in the
command synopsis, and connection_name is the parameter name more
commonly used in the docs for ECPG commands.
Reported-by: Yusuke Egashita
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/ecpg.sgml
Doc: document autovacuum interruption.
commit : 64e8a355635d5b9f28975020abc96a271c2b4817
author : Amit Kapila <[email protected]>
date : Thu, 19 Sep 2019 09:05:11 +0530
committer: Amit Kapila <[email protected]>
date : Thu, 19 Sep 2019 09:05:11 +0530
It's important users be able to know (without looking at the source code)
that running DDL or DDL-like commands can interrupt autovacuum which can
lead to a lot of dead tuples and hence slower database operations.
Reported-by: James Coleman
Author: James Coleman
Reviewed-by: Amit Kapila
Backpatch-through: 9.4
Discussion: https://postgr.es/m/CAAaqYe-XYyNwML1=f=gnd0qWg46PnvD=BDrCZ5-L94B887XVxQ@mail.gmail.com
M doc/src/sgml/maintenance.sgml
pg_upgrade/test.sh: Quote sed(1) argument
commit : 906a8078619593447fe7ee795895e476695c3235
author : Alvaro Herrera <[email protected]>
date : Wed, 18 Sep 2019 11:24:12 -0300
committer: Alvaro Herrera <[email protected]>
date : Wed, 18 Sep 2019 11:24:12 -0300
Lack of quotes results in failure to run the test under older Solaris.
Author: Marina Polyakova, Victor Wagner
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_upgrade/test.sh
Doc: Update FDW documentation about direct foreign table modification.
commit : dc99a05a86455e408fc0a5ce985aeb63e709ef7e
author : Etsuro Fujita <[email protected]>
date : Wed, 18 Sep 2019 18:50:05 +0900
committer: Etsuro Fujita <[email protected]>
date : Wed, 18 Sep 2019 18:50:05 +0900
1. Commit 7086be6e3 should have documented the limitation that the direct
modification is disabled when WCO constraints are present, but didn't,
which is definitely my fault. Update the documentation (Postgres 9.6
onwards).
2. Commit fc22b6623 should have documented the limitation that the direct
modification is disabled when generated columns are defined, but
didn't. Update the documentation (Postgres 12 onwards).
Author: Etsuro Fujita
Discussion: https://postgr.es/m/CAPmGK14AYCPunLb6TRz1CQsW5Le01Z2ox8LSOKH0P-cOVDcQRA%40mail.gmail.com
M doc/src/sgml/fdwhandler.sgml
Replace xlc __fetch_and_add() with inline asm.
commit : a1df9a015dac30d467a00f2d42510765d4f0dd5b
author : Noah Misch <[email protected]>
date : Fri, 13 Sep 2019 19:34:06 -0700
committer: Noah Misch <[email protected]>
date : Fri, 13 Sep 2019 19:34:06 -0700
PostgreSQL has been unusable when built with xlc 13 and newer, which are
incompatible with our use of __fetch_and_add(). Back-patch to 9.5,
which introduced pg_atomic_fetch_add_u32().
Reviewed by Tom Lane.
Discussion: https://postgr.es/m/[email protected]
M src/include/port/atomics/generic-xlc.h
Test pg_atomic_fetch_add_ with variable addend and 16-bit edge cases.
commit : 8d32f82cbbbba5dd3da76edc298c04d3fd6041ae
author : Noah Misch <[email protected]>
date : Fri, 13 Sep 2019 19:33:30 -0700
committer: Noah Misch <[email protected]>
date : Fri, 13 Sep 2019 19:33:30 -0700
Back-patch to 9.5, which introduced these functions.
Reviewed by Tom Lane.
Discussion: https://postgr.es/m/[email protected]
M src/test/regress/regress.c
logical decoding: process ASSIGNMENT during snapshot build
commit : ae4305f6d303d246b69a1fcdbb28f346d6a7f4db
author : Alvaro Herrera <[email protected]>
date : Fri, 13 Sep 2019 16:36:28 -0300
committer: Alvaro Herrera <[email protected]>
date : Fri, 13 Sep 2019 16:36:28 -0300
Most WAL records are ignored in early SnapBuild snapshot build phases.
But it's critical to process some of them, so that later messages have
the correct transaction state after the snapshot is completely built; in
particular, XLOG_XACT_ASSIGNMENT messages are critical in order for
sub-transactions to be correctly assigned to their parent transactions,
or at least one assert misbehaves, as reported by Ildar Musin.
Diagnosed-by: Masahiko Sawada
Author: Masahiko Sawada
Discussion: https://postgr.es/m/CAONYFtOv+Er1p3WAuwUsy1zsCFrSYvpHLhapC_fMD-zNaRWxYg@mail.gmail.com
M src/backend/replication/logical/decode.c
Fix under-parenthesized macro definitions
commit : 00f167bed782363b4fe05ecd870155eb84336a8b
author : Alvaro Herrera <[email protected]>
date : Fri, 13 Sep 2019 16:26:55 -0300
committer: Alvaro Herrera <[email protected]>
date : Fri, 13 Sep 2019 16:26:55 -0300
Lack of parens in the definitions could cause a statement using these
macros to have unexpected semantics. In current code no bug is
apparent, but best to fix the definitions to avoid problems down the
line.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
M src/include/nodes/parsenodes.h
Fix nbtree page split rmgr desc routine.
commit : 835646503d5d7782d890b7ad5039e64c08e2b89d
author : Peter Geoghegan <[email protected]>
date : Thu, 12 Sep 2019 15:45:01 -0700
committer: Peter Geoghegan <[email protected]>
date : Thu, 12 Sep 2019 15:45:01 -0700
Include newitemoff in rmgr desc output for nbtree page split records.
In passing, correct an obsolete comment that claimed that newitemoff is
only logged for _L variant nbtree page split WAL records.
Both issues were oversights in commit 2c03216d831, which revamped the
WAL format.
Author: Peter Geoghegan
Backpatch: 9.5-, where the WAL format was revamped.
M src/backend/access/rmgrdesc/nbtdesc.c
M src/include/access/nbtree.h
Fix usage of whole-row variables in WCO and RLS policy expressions.
commit : b00132b9a2b5fe0797a062c549d250435be08285
author : Tom Lane <[email protected]>
date : Thu, 12 Sep 2019 18:29:18 -0400
committer: Tom Lane <[email protected]>
date : Thu, 12 Sep 2019 18:29:18 -0400
Since WITH CHECK OPTION was introduced, ExecInitModifyTable has
initialized WCO expressions with the wrong plan node as parent -- that is,
it passed its input subplan not the ModifyTable node itself. Up to now
we thought this was harmless, but bug #16006 from Vinay Banakar shows it's
not: if the input node is a SubqueryScan then ExecInitWholeRowVar can get
confused into doing the wrong thing. (The fact that ExecInitWholeRowVar
contains such logic is certainly a horrid kluge that doesn't deserve to
live, but figuring out another way to do that is a task for some other day.)
Andres had already noticed the wrong-parent mistake and fixed it in commit
148e632c0, but not being aware of any user-visible consequences, he quite
reasonably didn't back-patch. This patch is simply a back-patch of
148e632c0, plus addition of a test case based on bug #16006. I also added
the test case to v12/HEAD, even though the bug is already fixed there.
Back-patch to all supported branches. 9.4 lacks RLS policies so the
new test case doesn't work there, but I'm pretty sure a test could be
devised based on using a whole-row Var in a plain WITH CHECK OPTION
condition. (I lack the cycles to do so myself, though.)
Andres Freund and Tom Lane
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/rowsecurity.sql
Remove pg_trgm.strict_word_similarity_threshold doc from 9.6 and 10
commit : b18aaad90fb14df8d211550f410fcb651e982ed4
author : Alexander Korotkov <[email protected]>
date : Thu, 12 Sep 2019 16:12:04 +0300
committer: Alexander Korotkov <[email protected]>
date : Thu, 12 Sep 2019 16:12:04 +0300
9ee98cc3f added missing doc for pg_trgm.strict_word_similarity_threshold GUC.
But it was accidentally backpatched to 9.6, while this GUC was introduced only
in 11. This patch removes extra doc from 9.6 and 10.
Discussion: https://postgr.es/m/CAHE3wghn%3DRyPWY-nxX1SiYAfkuwLHMd9Z4r8v9ww_jSs1jF5pg%40mail.gmail.com
Author: Euler Taveira
Backpatch-through: 9.6 and 10
M doc/src/sgml/pgtrgm.sgml
Doc: Update PL/pgSQL sample function in plpgsql.sgml.
commit : 2db5262549efe44f26b24dff6e82f554a60d84e4
author : Amit Kapila <[email protected]>
date : Wed, 11 Sep 2019 10:25:49 +0530
committer: Amit Kapila <[email protected]>
date : Wed, 11 Sep 2019 10:25:49 +0530
The example used to explain 'Looping Through Query Results' uses
pseudo-materialized views. Replace it with a more up-to-date example
which does the same thing with actual materialized views, which have
been available since PostgreSQL 9.3.
In the passing, change '%' as format specifier instead of '%s' as is used
in other examples in plpgsql.sgml.
Reported-by: Ian Barwick
Author: Ian Barwick
Reviewed-by: Amit Kapila
Backpatch-through: 9.4
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/plpgsql.sgml
Expand properly list of TAP tests used for prove in vcregress.pl
commit : e25c87a8e1a86b88911df81504d92235cdb49b6b
author : Michael Paquier <[email protected]>
date : Wed, 11 Sep 2019 11:07:39 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 11 Sep 2019 11:07:39 +0900
Depending on the system used, t/*.pl may not be expanded into a list of
tests which can be consumed by prove when attempting to run TAP tests on
a given path. Fix that by using glob() directly in the script, to make
sure that a complete list of tests is provided. This has not proved to
be an issue with MSVC as the list was properly expanded, but it is on
Linux with perl's system().
This is extracted from a larger patch.
Author: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M src/tools/msvc/vcregress.pl
Sync isolationtester's handling of notice/warning messages with HEAD.
commit : 5f0b71ee8532f54f3e1333853fd96293ca4aab9a
author : Tom Lane <[email protected]>
date : Tue, 10 Sep 2019 12:45:32 -0400
committer: Tom Lane <[email protected]>
date : Tue, 10 Sep 2019 12:45:32 -0400
Back-patch relevant parts of these commits:
30717637c Fix isolationtester race condition for notices sent before blocking
ebd499282 Don't drop NOTICE messages in isolation tests
a28e10e82 Indicate session name in isolationtester notices
This ensures that older versions of the isolationtester will handle
NOTICE/WARNING messages the same way as HEAD and v12 do. While this
isn't fixing any critical problem right now, it seems like a prudent
change to prevent surprises (like we had yesterday...) with
back-patches of future isolation test changes.
Back-patch as far as 9.6. Due to the significant changes we made in
isolationtester in 9.6, back-patching isolation tests further than
that is going to be risky anyway; besides, this patch doesn't apply
cleanly before that.
Discussion: https://postgr.es/m/[email protected]
M src/test/isolation/expected/insert-conflict-specconflict.out
M src/test/isolation/isolationtester.c
Prevent msys2 conversion of "cmd /c" switch to a file path
commit : 46ee1201c4710f9807bc444f61234ed1d70ee248
author : Andrew Dunstan <[email protected]>
date : Mon, 9 Sep 2019 08:56:33 -0400
committer: Andrew Dunstan <[email protected]>
date : Mon, 9 Sep 2019 08:56:33 -0400
Modern versions of msys2 have changed the treatment of "cmd /c" so that
the runtime will try to convert the switch to a native file path. This
patch adds a setting to inhibit that behaviour.
Discussion: https://postgr.es/m/[email protected]
Backpatch to all live branches.
M src/bin/pg_upgrade/test.sh
Always skip recovery SysV shared memory tests on Windows
commit : ef52d39bdf62bbe09fb727b359a0ffcd84f446c1
author : Andrew Dunstan <[email protected]>
date : Mon, 9 Sep 2019 08:42:06 -0400
committer: Andrew Dunstan <[email protected]>
date : Mon, 9 Sep 2019 08:42:06 -0400
These tests were disabled on git master in commit 8e5ce1c3f8. This does
the same thing on the back branches.
Discussion: https://postgr.es/m/[email protected]
M src/test/recovery/t/017_shm.pl
Fix RelationIdGetRelation calls that weren't bothering with error checks.
commit : 1d87b674828ad3d49b74d0190184d861f183fb30
author : Tom Lane <[email protected]>
date : Sun, 8 Sep 2019 17:00:29 -0400
committer: Tom Lane <[email protected]>
date : Sun, 8 Sep 2019 17:00:29 -0400
Some of these are quite old, but that doesn't make them not bugs.
We'd rather report a failure via elog than SIGSEGV.
While at it, uniformly spell the error check as !RelationIsValid(rel)
rather than a bare rel == NULL test. The machine code is the same
but it seems better to be consistent.
Coverity complained about this today, not sure why, because the
mistake is in fact old.
M src/backend/access/heap/heapam.c
M src/backend/replication/logical/reorderbuffer.c
Fix handling of NULL distances in KNN-GiST
commit : a5431b7d5f6bcccd1fc69c4e4ae6e4d5f39b83f8
author : Alexander Korotkov <[email protected]>
date : Sun, 8 Sep 2019 21:13:40 +0300
committer: Alexander Korotkov <[email protected]>
date : Sun, 8 Sep 2019 21:13:40 +0300
In order to implement NULL LAST semantic GiST previously assumed distance to
the NULL value to be Inf. However, our distance functions can return Inf and
NaN for non-null values. In such cases, NULL LAST semantic appears to be
broken. This commit fixes that by introducing separate array of null flags for
distances.
Backpatch to all supported versions.
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com
Author: Alexander Korotkov
Backpatch-through: 9.4
M src/backend/access/gist/gistget.c
M src/backend/access/gist/gistscan.c
M src/include/access/gist_private.h
Fix handling Inf and Nan values in GiST pairing heap comparator
commit : b2037afec14725e4521427edbee8071d04057a2d
author : Alexander Korotkov <[email protected]>
date : Sun, 8 Sep 2019 21:07:30 +0300
committer: Alexander Korotkov <[email protected]>
date : Sun, 8 Sep 2019 21:07:30 +0300
Previously plain float comparison was used in GiST pairing heap. Such
comparison doesn't provide proper ordering for value sets containing Inf and Nan
values. This commit fixes that by usage of float8_cmp_internal(). Note, there
is remaining problem with NULL distances, which are represented as Inf in
pairing heap. It would be fixes in subsequent commit.
Backpatch to all supported versions.
Reported-by: Andrey Borodin
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com
Author: Alexander Korotkov
Reviewed-by: Heikki Linnakangas
Backpatch-through: 9.4
M src/backend/access/gist/gistscan.c
configure: Update python search order
commit : 984ee0f6df06980a96b688342aad84ef47aea1fe
author : Tom Lane <[email protected]>
date : Sun, 8 Sep 2019 13:45:13 -0400
committer: Tom Lane <[email protected]>
date : Sun, 8 Sep 2019 13:45:13 -0400
Some systems don't ship with "python" by default anymore, only
"python3" or "python2" or some combination, so include those in the
configure search.
Back-patch of commit 7291733ac. At the time that was only pushed
back as far as v10, because of concerns about interactions with
commit b21c569ce. Closer analysis shows that if we just
s/AC_PATH_PROG/AC_PATH_PROGS/, there is no effect on the older
branches' behavior when PYTHON is explicitly specified, so it should
be okay to back-patch: this will not break any configuration that
worked before. And the need to support platforms with only a
"python3" or "python2" executable is getting ever more urgent.
Original patch by Peter Eisentraut, back-patch analysis by me
Discussion: https://www.postgresql.org/message-id/flat/1457.1543184081%40sss.pgh.pa.us#c9cc1199338fd6a257589c6dcea6cf8d
M config/python.m4
M configure
M doc/src/sgml/installation.sgml
doc: Fix awkward markup
commit : 0bea801c8176d14b7e22bc160cb96e6cf6650d61
author : Peter Eisentraut <[email protected]>
date : Fri, 6 Sep 2019 22:19:53 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 6 Sep 2019 22:19:53 +0200
M doc/src/sgml/ref/pg_dumpall.sgml
When performing a base backup, check for read errors.
commit : 23df8822601dce04d259fed0326ef28ecc6d1fa0
author : Robert Haas <[email protected]>
date : Fri, 6 Sep 2019 08:22:32 -0400
committer: Robert Haas <[email protected]>
date : Fri, 6 Sep 2019 08:22:32 -0400
The old code didn't differentiate between a read error and a
concurrent truncation. fread reports both of these by returning 0;
you have to use feof() or ferror() to distinguish between them,
which this code did not do.
It might be a better idea to use read() rather than fread() here,
so that we can display a less-generic error message, but I'm not
sure that would qualify as a back-patchable bug fix, so just do
this much for now.
Jeevan Chalke, reviewed by Jeevan Ladhe and by me.
Discussion: http://postgr.es/m/CA+TgmobG4ywMzL5oQq2a8YKp8x2p3p1LOMMcGqpS7aekT9+ETA@mail.gmail.com
M src/backend/replication/basebackup.c
Fix thinko when ending progress report for a backend
commit : f4b91a50e9e6757679322c454916bcd6b1dcbc15
author : Michael Paquier <[email protected]>
date : Wed, 4 Sep 2019 15:47:01 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 4 Sep 2019 15:47:01 +0900
The logic ending progress reporting for a backend entry introduced by
b6fb647 causes callers of pgstat_progress_end_command() to do some extra
work when track_activities is enabled as the process fields are reset in
the backend entry even if no command were started for reporting.
This resets the fields only if a command is registered for progress
reporting, and only if track_activities is enabled.
Author: Masahiho Sawada
Discussion: https://postgr.es/m/CAD21AoCry_vJ0E-m5oxJXGL3pnos-xYGCzF95rK5Bbi3Uf-rpA@mail.gmail.com
Backpatch-through: 9.6
M src/backend/postmaster/pgstat.c
Handle corner cases correctly in psql's reconnection logic.
commit : b0b2ef25e3ff240dc1887742bfed1d044c0938a0
author : Tom Lane <[email protected]>
date : Mon, 2 Sep 2019 14:02:46 -0400
committer: Tom Lane <[email protected]>
date : Mon, 2 Sep 2019 14:02:46 -0400
After an unexpected connection loss and successful reconnection,
psql neglected to resynchronize its internal state about the server,
such as server version. Ordinarily we'd be reconnecting to the same
server and so this isn't really necessary, but there are scenarios
where we do need to update --- one example is where we have a list
of possible connection targets and they're not all alike.
Define "resynchronize" as including connection_warnings(), so that
this case acts the same as \connect. This seems useful; for example,
if the server version did change, the user might wish to know that.
An attuned user might also notice that the new connection isn't
SSL-encrypted, for example, though this approach isn't especially
in-your-face about such changes. Although this part is a behavioral
change, it only affects interactive sessions, so it should not break
any applications.
Also, in do_connect, make sure that we desynchronize correctly when
abandoning an old connection in non-interactive mode.
These problems evidently are the result of people patching only one
of the two places where psql deals with connection changes, so insert
some cross-referencing comments in hopes of forestalling future bugs
of the same ilk.
Lastly, in Windows builds, issue codepage mismatch warnings only at
startup, not during reconnections. psql's codepage can't change
during a reconnect, so complaining about it again seems like useless
noise.
Peter Billen and Tom Lane. Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com
M src/bin/psql/command.c
M src/bin/psql/common.c
Doc: describe the "options" allowed in an ECPG connection target string.
commit : fd198a89ba8933192900a71337cb3e4e378f50b1
author : Tom Lane <[email protected]>
date : Sat, 31 Aug 2019 14:05:32 -0400
committer: Tom Lane <[email protected]>
date : Sat, 31 Aug 2019 14:05:32 -0400
These have been there a long time, but their format was never explained
in the docs. Per complaint from Yusuke Egashira.
Discussion: https://postgr.es/m/848B1649C8A6274AA527C4472CA11EDD5FC70CBE@G01JPEXMBYT02
M doc/src/sgml/ecpg.sgml
Fix overflow check and comment in GIN posting list encoding.
commit : e2e616579a15e677c1387ab7d41efabd51fecf0f
author : Heikki Linnakangas <[email protected]>
date : Wed, 28 Aug 2019 12:55:33 +0300
committer: Heikki Linnakangas <[email protected]>
date : Wed, 28 Aug 2019 12:55:33 +0300
The comment did not match what the code actually did for integers with
the 43rd bit set. You get an integer like that, if you have a posting
list with two adjacent TIDs that are more than 2^31 blocks apart.
According to the comment, we would store that in 6 bytes, with no
continuation bit on the 6th byte, but in reality, the code encodes it
using 7 bytes, with a continuation bit on the 6th byte as normal.
The decoding routine also handled these 7-byte integers correctly, except
for an overflow check that assumed that one integer needs at most 6 bytes.
Fix the overflow check, and fix the comment to match what the code
actually does. Also fix the comment that claimed that there are 17 unused
bits in the 64-bit representation of an item pointer. In reality, there
are 64-32-11=21.
Fitting any item pointer into max 6 bytes was an important property when
this was written, because in the old pre-9.4 format, item pointers were
stored as plain arrays, with 6 bytes for every item pointer. The maximum
of 6 bytes per integer in the new format guaranteed that we could convert
any page from the old format to the new format after upgrade, so that the
new format was never larger than the old format. But we hardly need to
worry about that anymore, and running into that problem during upgrade,
where an item pointer is expanded from 6 to 7 bytes such that the data
doesn't fit on a page anymore, is implausible in practice anyway.
Backpatch to all supported versions.
This also includes a little test module to test these large distances
between item pointers, without requiring a 16 TB table. It is not
backpatched, I'm including it more for the benefit of future development
of new posting list formats.
Discussion: https://www.postgresql.org/message-id/33bfc20a-5c86-f50c-f5a5-58e9925d05ff%40iki.fi
Reviewed-by: Masahiko Sawada, Alexander Korotkov
M src/backend/access/gin/ginpostinglist.c
Disable timeouts when running pg_rewind with online source cluster
commit : d64789e97cf6dea750027a2b7a6f7cf57dee1d5d
author : Michael Paquier <[email protected]>
date : Wed, 28 Aug 2019 11:48:29 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 28 Aug 2019 11:48:29 +0900
In this case, the transfer uses a libpq connection, which is subject to
the timeout parameters set at system level, and this can make the rewind
operation suddenly canceled which is not good for automation. One
workaround to such issues would be to use PGOPTIONS to enforce the
wanted timeout parameters, but that's annoying, and for example pg_dump,
which can run potentially long-running queries disables all types of
timeouts.
lock_timeout and statement_timeout are the ones which can cause problems
now. Note that pg_rewind does not use transactions, so disabling
idle_in_transaction_session_timeout is optional, but it feels safer to
do so for the future.
This is back-patched down to 9.5. idle_in_transaction_session_timeout
is only present since 9.6.
Author: Alexander Kukushkin
Discussion: https://postgr.es/m/CAFh8B=krcVXksxiwVQh1SoY+ziJ-JC=6FcuoBL3yce_40Es5_g@mail.gmail.com
Backpatch-through: 9.5
M src/bin/pg_rewind/libpq_fetch.c
Doc: clarify behavior of standard aggregates for null inputs.
commit : 5efa4a3e7008638732d14ffd7613f53823a75367
author : Tom Lane <[email protected]>
date : Tue, 27 Aug 2019 16:37:22 -0400
committer: Tom Lane <[email protected]>
date : Tue, 27 Aug 2019 16:37:22 -0400
Section 4.2.7 says that unless otherwise specified, built-in
aggregates ignore rows in which any input is null. This is
not true of the JSON aggregates, but it wasn't documented.
Fix that.
Of the other entries in table 9.55, some were explicit about
ignoring nulls, and some weren't; for consistency and
self-contained-ness, make them all say it explicitly.
Per bug #15884 from Tim Möhlmann. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/func.sgml
Reject empty names and recursion in config-file include directives.
commit : 465f4dddae6bfe882f95e9e04633c7c496826ac2
author : Tom Lane <[email protected]>
date : Tue, 27 Aug 2019 14:44:26 -0400
committer: Tom Lane <[email protected]>
date : Tue, 27 Aug 2019 14:44:26 -0400
An empty file name or subdirectory name leads join_path_components() to
just produce the parent directory name, which leads to weird failures or
recursive inclusions. Let's throw a specific error for that. It takes
only slightly more code to detect all-blank names, so do so.
Also, detect direct recursion, ie a file calling itself. As coded
this will also detect recursion via "include_dir '.'", which is
perhaps more likely than explicitly including the file itself.
Detecting indirect recursion would require API changes for guc-file.l
functions, which seems not worth it since extensions might call them.
The nesting depth limit will catch such cases eventually, just not
with such an on-point error message.
In passing, adjust the example usages in postgresql.conf.sample
to perhaps eliminate the problem at the source: there's no reason
for the examples to suggest that an empty value is valid.
Per a trouble report from Brent Bates. Back-patch to 9.5; the
issue is old, but the code in 9.4 is enough different that the
patch doesn't apply easily, and it doesn't seem worth the trouble
to fix there.
Ian Barwick and Tom Lane
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/misc/guc-file.l
M src/backend/utils/misc/postgresql.conf.sample
Fix failure of --jobs with vacuumdb on Windows
commit : c4d75313ee7ba173d00272fb1f0b7b1aebbb2f58
author : Michael Paquier <[email protected]>
date : Tue, 27 Aug 2019 09:12:10 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 27 Aug 2019 09:12:10 +0900
FD_SETSIZE needs to be declared before winsock2.h, or it is possible to
run into buffer overflow issues when using --jobs. This is similar to
pgbench's solution done in a23c641.
This has been introduced by 71d84ef, and older versions have been using
the default value of FD_SETSIZE, defined at 64. While on it, add a
missing newline to the previously-added error message.
Per buildfarm member jacana, but this impacts all Windows animals
running the TAP tests. I have reproduced the failure locally to check
the patch.
Author: Michael Paquier
Reviewed-by: Andrew Dunstan
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
M src/bin/scripts/vacuumdb.c
Treat MINGW and MSYS the same in pg_upgrade test script
commit : f6d5a5f6dba515db39047ec07240129090d71538
author : Andrew Dunstan <[email protected]>
date : Mon, 26 Aug 2019 07:44:34 -0400
committer: Andrew Dunstan <[email protected]>
date : Mon, 26 Aug 2019 07:44:34 -0400
On msys2, 'uname -s' reports a string starting MSYS instead on MINGW
as happens on msys1. Treat these both the same way. This reverts
608a710195a4b in favor of a more general solution.
Backpatch to all live branches.
M src/bin/pg_upgrade/test.sh
Fix error handling of vacuumdb when running out of fds
commit : eb91b8ee65721f7e4df218b7a438d9c55e7b972f
author : Michael Paquier <[email protected]>
date : Mon, 26 Aug 2019 11:14:39 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 26 Aug 2019 11:14:39 +0900
When trying to use a high number of jobs, vacuumdb has only checked for
a maximum number of jobs used, causing confusing failures when running
out of file descriptors when the jobs open connections to Postgres.
This commit changes the error handling so as we do not check anymore for
a maximum number of allowed jobs when parsing the option value with
FD_SETSIZE, but check instead if a file descriptor is within the
supported range when opening the connections for the jobs so as this is
detected at the earliest time possible.
Also, improve the error message to give a hint about the number of jobs
recommended, using a wording given by the reviewers of the patch.
Reported-by: Andres Freund
Author: Michael Paquier
Reviewed-by: Andres Freund, Álvaro Herrera, Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
M src/bin/scripts/vacuumdb.c
Avoid platform-specific null pointer dereference in psql.
commit : 28d2ce3c7c992c1aa2bbab984f14bf98056f3864
author : Tom Lane <[email protected]>
date : Sun, 25 Aug 2019 15:04:04 -0400
committer: Tom Lane <[email protected]>
date : Sun, 25 Aug 2019 15:04:04 -0400
POSIX permits getopt() to advance optind beyond argc when the last
argv entry is an option that requires an argument and hasn't got one.
It seems that no major platforms actually do that, but musl does,
so that something like "psql -f" would crash with that libc.
Add a check that optind is in range before trying to look at the
possibly-bogus option.
Report and fix by Quentin Rameau. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/bin/psql/startup.c
Doc: Remove mention to "Visual Studio Express 2019"
commit : c7d8245b09a080143c53d5cc7a9c7f5fce475eed
author : Michael Paquier <[email protected]>
date : Thu, 22 Aug 2019 09:59:39 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 22 Aug 2019 09:59:39 +0900
The "Express" flavor of Visual Studio exists up to 2017, and the
documentation referred to "Express" for Visual Studio 2019.
Author: Takuma Hoshiai
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/install-windows.sgml
Fix typo
commit : fe7262f0d8cea4fd6a64bb1361da5d7e47040d86
author : Alvaro Herrera <[email protected]>
date : Wed, 21 Aug 2019 11:12:44 -0400
committer: Alvaro Herrera <[email protected]>
date : Wed, 21 Aug 2019 11:12:44 -0400
In early development patches, "replication origins" were called "identifiers";
almost everything was renamed, but these references to the old terminology
went unnoticed.
Reported-by: Craig Ringer
M src/backend/replication/logical/origin.c
Fix bogus comment
commit : 516613d4a16a8e360b9e07d2fcbbdec96efb8cce
author : Alvaro Herrera <[email protected]>
date : Tue, 20 Aug 2019 16:04:09 -0400
committer: Alvaro Herrera <[email protected]>
date : Tue, 20 Aug 2019 16:04:09 -0400
Author: Alexander Lakhin
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/heap/heapam.c
Doc: Fix various typos
commit : 3399b345f1d4047b7c2777946bdd05b1938ed6d1
author : Michael Paquier <[email protected]>
date : Tue, 20 Aug 2019 13:46:14 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 20 Aug 2019 13:46:14 +0900
All those fixes are already included on HEAD thanks to for example
c96581a and 66bde49, and have gone missing on back-branches.
Author: Alexander Lakhin, Liudmila Mantrova
Discussion: https://postgr.es/m/CAEkD-mDJHV3bhgezu3MUafJLoAKsOOT86+wHukKU8_NeiJYhLQ@mail.gmail.com
Backpatch-through: 9.4
M doc/src/sgml/custom-scan.sgml
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/gist.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/problems.sgml
M doc/src/sgml/ref/create_aggregate.sgml
M doc/src/sgml/ref/set_role.sgml
M doc/src/sgml/sources.sgml
M doc/src/sgml/sslinfo.sgml
M doc/src/sgml/xplang.sgml
Disallow changing an inherited column's type if not all parents changed.
commit : 3442235f2a8d902fb3f8664dd71dfaa258ba656a
author : Tom Lane <[email protected]>
date : Sun, 18 Aug 2019 17:11:58 -0400
committer: Tom Lane <[email protected]>
date : Sun, 18 Aug 2019 17:11:58 -0400
If a table inherits from multiple unrelated parents, we must disallow
changing the type of a column inherited from multiple such parents, else
it would be out of step with the other parents. However, it's possible
for the column to ultimately be inherited from just one common ancestor,
in which case a change starting from that ancestor should still be
allowed. (I would not be excited about preserving that option, were
it not that we have regression test cases exercising it already ...)
It's slightly annoying that this patch looks different from the logic
with the same end goal in renameatt(), and more annoying that it
requires an extra syscache lookup to make the test. However, the
recursion logic is quite different in the two functions, and a
back-patched bug fix is no place to be trying to unify them.
Per report from Manuel Rigger. Back-patch to 9.5. The bug exists in
9.4 too (and doubtless much further back); but the way the recursion
is done in 9.4 is a good bit different, so that substantial refactoring
would be needed to fix it in 9.4. I'm disinclined to do that, or risk
introducing new bugs, for a bug that has escaped notice for this long.
Discussion: https://postgr.es/m/CA+u7OA4qogDv9rz1HAb-ADxttXYPqQdUdPY_yd4kCzywNxRQXA@mail.gmail.com
M src/backend/commands/tablecmds.c
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Prevent possible double-free when update trigger returns old tuple.
commit : 1fe8d209ed84c6d5d8e568a836719924deaa9b8b
author : Tom Lane <[email protected]>
date : Thu, 15 Aug 2019 20:04:19 -0400
committer: Tom Lane <[email protected]>
date : Thu, 15 Aug 2019 20:04:19 -0400
This is a variant of the problem fixed in commit 25b692568, which
unfortunately we failed to detect at the time. If an update trigger
returns the "old" tuple, as it's entitled to do, then a subsequent
iteration of the loop in ExecBRUpdateTriggers would have "oldtuple"
equal to "trigtuple" and would fail to notice that it shouldn't
free that.
In addition to fixing the code, extend the test case added by
25b692568 so that it covers multiple-trigger-iterations cases.
This problem does not manifest in v12/HEAD, as a result of the
relevant code having been largely rewritten for slotification.
However, include the test case into v12/HEAD anyway, since this
is clearly an area that someone could break again in future.
Per report from Piotr Gabriel Kosinski. Back-patch into all
supported branches, since the bug seems quite old.
Diagnosis and code fix by Thomas Munro, test case by me.
Discussion: https://postgr.es/m/CAFMLSdP0rd7LqC3j-H6Fh51FYSt5A10DDh-3=W4PPc4LLUQ8YQ@mail.gmail.com
M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Doc: improve documentation about postgresql.auto.conf.
commit : 0969a7aa3240eaa27f6978da6870f9eef706b356
author : Tom Lane <[email protected]>
date : Thu, 15 Aug 2019 11:14:26 -0400
committer: Tom Lane <[email protected]>
date : Thu, 15 Aug 2019 11:14:26 -0400
Clarify what external tools can do to this file, and add a bit
of detail about what ALTER SYSTEM itself does.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/config.sgml
Fix ALTER SYSTEM to cope with duplicate entries in postgresql.auto.conf.
commit : 4784ad7a370ebdbde7aeaa9faf0f0c00b245f1a4
author : Tom Lane <[email protected]>
date : Wed, 14 Aug 2019 15:09:20 -0400
committer: Tom Lane <[email protected]>
date : Wed, 14 Aug 2019 15:09:20 -0400
ALTER SYSTEM itself normally won't make duplicate entries (although
up till this patch, it was possible to confuse it by writing case
variants of a GUC's name). However, if some external tool has appended
entries to the file, that could result in duplicate entries for a single
GUC name. In such a situation, ALTER SYSTEM did exactly the wrong thing,
because it replaced or removed only the first matching entry, leaving
the later one(s) still there and hence still determining the active value.
This patch fixes that by making ALTER SYSTEM sweep through the file and
remove all matching entries, then (if not ALTER SYSTEM RESET) append the
new setting to the end. This means entries will be in order of last
setting rather than first setting, but that shouldn't hurt anything.
Also, make the comparisons case-insensitive so that the right things
happen if you do, say, ALTER SYSTEM SET "TimeZone" = 'whatever'.
This has been broken since ALTER SYSTEM was invented, so back-patch
to all supported branches.
Ian Barwick, with minor mods by me
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/misc/guc.c
Un-break pg_dump for pre-8.3 source servers.
commit : 2b608ba313147553370b233f031f84f0ed77df3f
author : Tom Lane <[email protected]>
date : Tue, 13 Aug 2019 16:57:59 -0400
committer: Tom Lane <[email protected]>
date : Tue, 13 Aug 2019 16:57:59 -0400
Commit 07b39083c inserted an unconditional reference to pg_opfamily,
which of course fails on servers predating that catalog. Fortunately,
the case it's trying to solve can't occur on such old servers (AFAIK).
Hence, just skip the additional code when the source predates 8.3.
Per bug #15955 from sly. Back-patch to all supported branches,
like the previous patch.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_dump/pg_dump.c
Fix compiler warning
commit : 99493bcbe79dcc0c6efb59af25aca86baf649ab2
author : Peter Eisentraut <[email protected]>
date : Mon, 12 Aug 2019 21:20:14 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 12 Aug 2019 21:20:14 +0200
With some newer gcc versions (8 and 9) you get a -Wformat-overflow
warning here. In PG11 and later this was already fixed. Since it's
trivial, backport it to get the older branches building without
warnings.
M src/bin/pgbench/pgbench.c
Doc: document permissions required for ANALYZE.
commit : 5ce3b55520538ff9efeef4f36536e3c893413a30
author : Tom Lane <[email protected]>
date : Wed, 7 Aug 2019 18:09:28 -0400
committer: Tom Lane <[email protected]>
date : Wed, 7 Aug 2019 18:09:28 -0400
VACUUM's reference page had this text, but ANALYZE's didn't. That's
a clear oversight given that section 5.7 explicitly delegates the
responsibility to define permissions requirements to the individual
commands' man pages.
Per gripe from Isaac Morland. Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAMsGm5fp3oBUs-2iRfii0iEO=fZuJALVyM2zJLhNTjG34gpAVQ@mail.gmail.com
M doc/src/sgml/ref/analyze.sgml
Fix predicate-locking of HOT updated rows.
commit : 75774cc221e50a408267a1f09af7f09f44999c0b
author : Heikki Linnakangas <[email protected]>
date : Wed, 7 Aug 2019 12:40:49 +0300
committer: Heikki Linnakangas <[email protected]>
date : Wed, 7 Aug 2019 12:40:49 +0300
In serializable mode, heap_hot_search_buffer() incorrectly acquired a
predicate lock on the root tuple, not the returned tuple that satisfied
the visibility checks. As explained in README-SSI, the predicate lock does
not need to be copied or extended to other tuple versions, but for that to
work, the correct, visible, tuple version must be locked in the first
place.
The original SSI commit had this bug in it, but it was fixed back in 2013,
in commit 81fbbfe335. But unfortunately, it was reintroduced a few months
later in commit b89e151054. Wising up from that, add a regression test
to cover this, so that it doesn't get reintroduced again. Also, move the
code that sets 't_self', so that it happens at the same time that the
other HeapTuple fields are set, to make it more clear that all the code in
the loop operate on the "current" tuple in the chain, not the root tuple.
Bug spotted by Andres Freund, analysis and original fix by Thomas Munro,
test case and some additional changes to the fix by Heikki Linnakangas.
Backpatch to all supported versions (9.4).
Discussion: https://www.postgresql.org/message-id/20190731210630.nqhszuktygwftjty%40alap3.anarazel.de
M src/backend/access/heap/heapam.c
A src/test/isolation/expected/predicate-lock-hot-tuple.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/predicate-lock-hot-tuple.spec
Fix some incorrect parsing of time with time zone strings
commit : 7c64a2cd9446629493aadb9620e1ff77597ec27d
author : Michael Paquier <[email protected]>
date : Wed, 7 Aug 2019 18:17:52 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 7 Aug 2019 18:17:52 +0900
When parsing a timetz string with a dynamic timezone abbreviation or a
timezone not specified, it was possible to generate incorrect timestamps
based on a date which uses some non-initialized variables if the input
string did not specify fully a date to parse. This is already checked
when a full timezone spec is included in the input string, but the two
other cases mentioned above missed the same checks.
This gets fixed by generating an error as this input is invalid, or in
short when a date is not fully specified.
Valgrind was complaining about this problem.
Bug: #15910
Author: Alexander Lakhin
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M src/backend/utils/adt/datetime.c
M src/test/regress/expected/timetz.out
M src/test/regress/sql/timetz.sql
Fix intarray's GiST opclasses to not fail for empty arrays with <@.
commit : e519eded65304be125787908a9343eee66a01860
author : Tom Lane <[email protected]>
date : Tue, 6 Aug 2019 18:04:51 -0400
committer: Tom Lane <[email protected]>
date : Tue, 6 Aug 2019 18:04:51 -0400
contrib/intarray considers "arraycol <@ constant-array" to be indexable,
but its GiST opclass code fails to reliably find index entries for empty
array values (which of course should trivially match such queries).
This is because the test condition to see whether we should descend
through a non-leaf node is wrong.
Unfortunately, empty array entries could be anywhere in the index,
as these index opclasses are currently designed. So there's no way
to fix this except by lobotomizing <@ indexscans to scan the whole
index ... which is what this patch does. That's pretty unfortunate:
the performance is now actually worse than a seqscan, in most cases.
We'd be better off to remove <@ from the GiST opclasses entirely,
and perhaps a future non-back-patchable patch will do so.
In the meantime, applications whose performance is adversely impacted
have a couple of options. They could switch to a GIN index, which
doesn't have this bug, or they could replace "arraycol <@ constant-array"
with "arraycol <@ constant-array AND arraycol && constant-array".
That will provide about the same performance as before, and it will find
all non-empty subsets of the given constant-array, which is all that
could reliably be expected of the query before.
While at it, add some more regression test cases to improve code
coverage of contrib/intarray.
In passing, adjust resize_intArrayType so that when it's returning an
empty array, it uses construct_empty_array for that rather than
cowboy hacking on the input array. While the hack produces an array
that looks valid for most purposes, it isn't bitwise equal to empty
arrays produced by other code paths, which could have subtle odd
effects. I don't think this code path is performance-critical
enough to justify such shortcuts. (Back-patch this part only as far
as v11; before commit 01783ac36 we were not careful about this in
other intarray code paths either.)
Back-patch the <@ fixes to all supported versions, since this was
broken from day one.
Patch by me; thanks to Alexander Korotkov for review.
Discussion: https://postgr.es/m/[email protected]
M contrib/intarray/_int_gist.c
M contrib/intarray/_intbig_gist.c
M contrib/intarray/expected/_int.out
M contrib/intarray/sql/_int.sql