PostgreSQL 9.4.19 commit log

Stamp 9.4.19.

commit   : 895fb6e2e270654b2a89042ddaf7db0e1a29003c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 16:11:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 16:11:24 -0400    

Click here for diff

M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc

Translation updates

commit   : 1af8bbe9abab91b2f269cc6dddcc9b7e5350929d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 6 Aug 2018 19:31:39 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 6 Aug 2018 19:31:39 +0200    

Click here for diff

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: a69444e557347b0db244ac3d3ea2bf602a82227f  

M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/bin/initdb/po/cs.po
M src/bin/pg_basebackup/nls.mk
A src/bin/pg_basebackup/po/cs.po
M src/bin/pg_config/po/cs.po
M src/bin/pg_controldata/po/cs.po
M src/bin/pg_ctl/po/cs.po
M src/bin/pg_dump/po/cs.po
M src/bin/pg_resetxlog/po/cs.po
M src/bin/psql/po/cs.po
M src/bin/scripts/po/cs.po
M src/interfaces/ecpg/ecpglib/po/cs.po
M src/interfaces/ecpg/preproc/po/cs.po
M src/interfaces/libpq/po/cs.po
M src/pl/plperl/po/cs.po
M src/pl/plpgsql/src/po/cs.po
M src/pl/plpython/po/cs.po
M src/pl/tcl/po/cs.po

Last-minute updates for release notes.

commit   : c54f04820a48c33ca15b24552eab29f5137ce462    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 13:13:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 13:13:41 -0400    

Click here for diff

Security: CVE-2018-10915, CVE-2018-10925  

M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml

Fix failure to reset libpq’s state fully between connection attempts.

commit   : 6de9766b8d56c292a2d446424b417817475a3e32    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 10:53:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 10:53:35 -0400    

Click here for diff

The logic in PQconnectPoll() did not take care to ensure that all of  
a PGconn's internal state variables were reset before trying a new  
connection attempt.  If we got far enough in the connection sequence  
to have changed any of these variables, and then decided to try a new  
server address or server name, the new connection might be completed  
with some state that really only applied to the failed connection.  
  
While this has assorted bad consequences, the only one that is clearly  
a security issue is that password_needed didn't get reset, so that  
if the first server asked for a password and the second didn't,  
PQconnectionUsedPassword() would return an incorrect result.  This  
could be leveraged by unprivileged users of dblink or postgres_fdw  
to allow them to use server-side login credentials that they should  
not be able to use.  
  
Other notable problems include the possibility of forcing a v2-protocol  
connection to a server capable of supporting v3, or overriding  
"sslmode=prefer" to cause a non-encrypted connection to a server that  
would have accepted an encrypted one.  Those are certainly bugs but  
it's harder to paint them as security problems in themselves.  However,  
forcing a v2-protocol connection could result in libpq having a wrong  
idea of the server's standard_conforming_strings setting, which opens  
the door to SQL-injection attacks.  The extent to which that's actually  
a problem, given the prerequisite that the attacker needs control of  
the client's connection parameters, is unclear.  
  
These problems have existed for a long time, but became more easily  
exploitable in v10, both because it introduced easy ways to force libpq  
to abandon a connection attempt at a late stage and then try another one  
(rather than just giving up), and because it provided an easy way to  
specify multiple target hosts.  
  
Fix by rearranging PQconnectPoll's state machine to provide centralized  
places to reset state properly when moving to a new target host or when  
dropping and retrying a connection to the same host.  
  
Tom Lane, reviewed by Noah Misch.  Our thanks to Andrew Krasichkov  
for finding and reporting the problem.  
  
Security: CVE-2018-10915  

M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/libpq-int.h

Release notes for 10.5, 9.6.10, 9.5.14, 9.4.19, 9.3.24.

commit   : b27db48749256cfdd41c4ae4443120a28593e19b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Aug 2018 16:38:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Aug 2018 16:38:43 -0400    

Click here for diff

M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml

Doc: fix incorrectly stated argument list for pgcrypto’s hmac() function.

commit   : 0720049ce1c8b526c9e63f6d92732cee3d0e0c17    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Aug 2018 13:03:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Aug 2018 13:03:42 -0400    

Click here for diff

The bytea variant takes (bytea, bytea, text).  
Per unsigned report.  
  
Discussion: https://postgr.es/m/153344327294.1404.654155870612982042@wrigleys.postgresql.org  

M doc/src/sgml/pgcrypto.sgml

Reset properly errno before calling write()

commit   : e69a3ac4a3e0ba640264a94dded197c21c33aa11    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 5 Aug 2018 05:32:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 5 Aug 2018 05:32:44 +0900    

Click here for diff

6cb3372 enforces errno to ENOSPC when less bytes than what is expected  
have been written when it is unset, though it forgot to properly reset  
errno before doing a system call to write(), causing errno to  
potentially come from a previous system call.  
  
Reported-by: Tom Lane  
Author: Michael Paquier  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/31797.1533326676@sss.pgh.pa.us  

M src/backend/access/heap/rewriteheap.c
M src/backend/access/transam/twophase.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
M src/backend/replication/slot.c
M src/bin/pg_basebackup/receivelog.c

Add table relcache invalidation to index builds.

commit   : 250528cec09fa56c27915b5a18ec8fae37c2b447    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 3 Aug 2018 14:44:33 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 3 Aug 2018 14:44:33 -0700    

Click here for diff

It's necessary to make sure that owning tables have a relcache  
invalidation prior to advancing the command counter to make  
newly-entered catalog tuples for the index visible.  inval.c must be  
able to maintain the consistency of the local caches in the event of  
transaction abort.  There is usually only a problem when CREATE INDEX  
transactions abort, since there is a generic invalidation once we reach  
index_update_stats().  
  
This bug is of long standing.  Problems were made much more likely by  
the addition of parallel CREATE INDEX (commit 9da0cc35284), but it is  
strongly suspected that similar problems can be triggered without  
involving plan_create_index_workers().  (plan_create_index_workers()  
triggers a relcache build or rebuild, which previously only happened in  
rare edge cases.)  
  
Author: Peter Geoghegan  
Reported-By: Luca Ferrari  
Diagnosed-By: Andres Freund  
Reviewed-By: Andres Freund  
Discussion: https://postgr.es/m/CAKoxK+5fVodiCtMsXKV_1YAKXbzwSfp7DgDqUmcUAzeAhf=HEQ@mail.gmail.com  
Backpatch: 9.3-  

M src/backend/catalog/index.c

pg_upgrade: fix –check for live source server checks

commit   : 12dd070081de931a45af42bbdacc65ff0f8066eb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Jul 2018 18:10:06 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Jul 2018 18:10:06 -0400    

Click here for diff

Fix for commit 244142d32afd02e7408a2ef1f249b00393983822.  
  
Backpatch-through: 9.3  

M contrib/pg_upgrade/controldata.c

Further fixes for quoted-list GUC values in pg_dump and ruleutils.c.

commit   : 88adf1add2935b4ab06197f03c822ea5849f2b44    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jul 2018 13:00:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jul 2018 13:00:08 -0400    

Click here for diff

Commits 742869946 et al turn out to be a couple bricks shy of a load.  
We were dumping the stored values of GUC_LIST_QUOTE variables as they  
appear in proconfig or setconfig catalog columns.  However, although that  
quoting rule looks a lot like SQL-identifier double quotes, there are two  
critical differences: empty strings ("") are legal, and depending on which  
variable you're considering, values longer than NAMEDATALEN might be valid  
too.  So the current technique fails altogether on empty-string list  
entries (as reported by Steven Winfield in bug #15248) and it also risks  
truncating file pathnames during dump/reload of GUC values that are lists  
of pathnames.  
  
To fix, split the stored value without any downcasing or truncation,  
and then emit each element as a SQL string literal.  
  
This is a tad annoying, because we now have three copies of the  
comma-separated-string splitting logic in varlena.c as well as a fourth  
one in dumputils.c.  (Not to mention the randomly-different-from-those  
splitting logic in libpq...)  I looked at unifying these, but it would  
be rather a mess unless we're willing to tweak the API definitions of  
SplitIdentifierString, SplitDirectoriesString, or both.  That might be  
worth doing in future; but it seems pretty unsafe for a back-patched  
bug fix, so for now accept the duplication.  
  
Back-patch to all supported branches, as the previous fix was.  
  
Discussion: https://postgr.es/m/7585.1529435872@sss.pgh.pa.us  

M src/backend/utils/adt/ruleutils.c
M src/backend/utils/adt/varlena.c
M src/bin/pg_dump/dumputils.c
M src/bin/pg_dump/dumputils.h
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dumpall.c
M src/include/utils/builtins.h
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql

Fix pg_dump’s failure to dump REPLICA IDENTITY for constraint indexes.

commit   : addf9e1bd6e98f3f350e0d4e045757449df25bf9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jul 2018 12:35:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jul 2018 12:35:49 -0400    

Click here for diff

pg_dump knew about printing ALTER TABLE ... REPLICA IDENTITY USING INDEX  
for indexes declared as indexes, but it failed to print that for indexes  
declared as unique or primary-key constraints.  Per report from Achilleas  
Mantzios.  
  
This has been broken since the feature was introduced, AFAICS.  
Back-patch to 9.4.  
  
Discussion: https://postgr.es/m/1e6cc5ad-b84a-7c07-8c08-a4d0c3cdc938@matrix.gatewaynet.com  

M src/bin/pg_dump/pg_dump.c

Fix earthdistance test suite function name typo.

commit   : 5649332bcdc9e5ebe6f4d8d27ef44c5567996378    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 29 Jul 2018 12:02:07 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 29 Jul 2018 12:02:07 -0700    

Click here for diff

Affected test queries have been testing the wrong thing since their  
introduction in commit 4c1383efd132e4f532213c8a8cc63a455f55e344.  
Back-patch to 9.3 (all supported versions).  

M contrib/earthdistance/expected/earthdistance.out
M contrib/earthdistance/sql/earthdistance.sql

Document security implications of qualified names.

commit   : 8c477a42eb9bdb91e7361645c3c343578000cb4a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 28 Jul 2018 20:08:01 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 28 Jul 2018 20:08:01 -0700    

Click here for diff

Commit 5770172cb0c9df9e6ce27c507b449557e5b45124 documented secure schema  
usage, and that advice suffices for using unqualified names securely.  
Document, in typeconv-func primarily, the additional issues that arise  
with qualified names.  Back-patch to 9.3 (all supported versions).  
  
Reviewed by Jonathan S. Katz.  
  
Discussion: https://postgr.es/m/20180721012446.GA1840594@rfd.leadboat.com  

M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_function.sgml
M doc/src/sgml/syntax.sgml
M doc/src/sgml/typeconv.sgml
M doc/src/sgml/xfunc.sgml
M src/backend/utils/adt/ruleutils.c

pg_upgrade: check for clean server shutdowns

commit   : f878781066f64a82238423cc81cdf1f8f75a013d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 28 Jul 2018 15:01:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 28 Jul 2018 15:01:55 -0400    

Click here for diff

Previously pg_upgrade checked for the pid file and started/stopped the  
server to force a clean shutdown.  However, "pg_ctl -m immediate"  
removes the pid file but doesn't do a clean shutdown, so check  
pg_controldata for a clean shutdown too.  
  
Diagnosed-by: Vimalraj A  
  
Discussion: https://postgr.es/m/CAFKBAK5e4Q-oTUuPPJ56EU_d2Rzodq6GWKS3ncAk3xo7hAsOZg@mail.gmail.com  
  
Backpatch-through: 9.3  

M contrib/pg_upgrade/controldata.c
M contrib/pg_upgrade/pg_upgrade.c

doc: Fix reference to “decoder” to instead be the correct “output plugin”.

commit   : 1cf1d2d6058133b2761633cf0e855592c98f0768    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 24 Jul 2018 10:51:21 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 24 Jul 2018 10:51:21 -0700    

Click here for diff

Author: Jonathan Katz  
Discussion: https://postgr.es/m/DD02DD86-5989-4BFD-8712-468541F68383@postgresql.org  
Backpatch: 9.4-, where logical decoding was added  

M doc/src/sgml/test-decoding.sgml

Further portability hacking in pg_upgrade’s test script.

commit   : ab57f48f682458cb691ee2c02e219ce0d762c7c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jul 2018 15:40:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jul 2018 15:40:52 -0400    

Click here for diff

I blew the dust off a Bourne shell (file date 1996, yea verily) and  
tried to run test.sh with it.  It mostly worked, but I found that the  
temp-directory creation code introduced by commit be76a6d39 was not  
compatible, for a couple of reasons: this shell thinks "set -e" should  
force an exit if a command within backticks fails, and it also thinks code  
within braces should be executed by a sub-shell, meaning that variable  
settings don't propagate back up to the parent shell.  In view of Victor  
Wagner's report that Solaris is still using pre-POSIX shells, seems like  
we oughta make this case work.  It's not like the code is any less  
idiomatic this way; the prior coding technique appeared nowhere else.  
  
(There is a remaining bash-ism here, which is that $RANDOM doesn't do  
what the code hopes in non-bash shells.  But the use of $$ elsewhere in  
that path should be enough to ensure uniqueness and some amount of  
randomness, so I think it's okay as-is.)  
  
Back-patch to all supported branches, as the previous commit was.  
  
Discussion: https://postgr.es/m/20180720153820.69e9ae6c@fafnir.local.vm  

M contrib/pg_upgrade/test.sh

Fix handling of empty uncompressed posting list pages in GIN

commit   : 9c6a676c4cedab50e4015f49c871dbcdfc4efe07    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Jul 2018 21:04:17 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Jul 2018 21:04:17 +0300    

Click here for diff

PostgreSQL 9.4 introduces posting list compression in GIN.  This feature  
supports online upgrade, so that after pg_upgrade uncompressed posting  
lists are compressed on-the-fly.  Underlying code appears to always  
expect at least one item on uncompressed posting list page.  But there  
could be completely empty pages, because VACUUM never deletes leftmost  
and rightmost pages from posting trees.  This commit fixes that.  
  
Reported-by: Sivasubramanian Ramasubramanian  
Discussion: https://postgr.es/m/1531867212836.63354%40amazon.com  
Author: Sivasubramanian Ramasubramanian, Alexander Korotkov  
Backpatch-through: 9.4  

M src/backend/access/gin/gindatapage.c
M src/backend/access/gin/ginxlog.c

Fix misc typos, mostly in comments.

commit   : 47d51a5e8cac65313c753c34ec1a3a7519c59098    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Jul 2018 16:10:44 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Jul 2018 16:10:44 +0300    

Click here for diff

A collection of typos I happened to spot while reading code, as well as  
grepping for common mistakes.  
  
Backpatch to all supported versions, as applicable, to avoid conflicts  
when backporting other commits in the future.  

M contrib/pg_upgrade/tablespace.c
M src/backend/commands/cluster.c
M src/interfaces/ecpg/ecpglib/execute.c
M src/pl/tcl/pltcl.c

Fix crash in contrib/ltree’s lca() function for empty input array.

commit   : f8e8be7f2f9ef9162985ca1a8f4cc41940363522    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Jul 2018 18:45:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Jul 2018 18:45:30 -0400    

Click here for diff

lca_inner() wasn't prepared for the possibility of getting no inputs.  
Fix that, and make some cosmetic improvements to the code while at it.  
  
Also, I thought the documentation of this function as returning the  
"longest common prefix" of the paths was entirely misleading; it really  
returns a path one shorter than the longest common prefix, for the typical  
definition of "prefix".  Don't use that term in the docs, and adjust the  
examples to clarify what really happens.  
  
This has been broken since its beginning, so back-patch to all supported  
branches.  
  
Per report from Hailong Li.  Thanks to Pierre Ducroquet for diagnosing  
and for the initial patch, though I whacked it around some and added  
test cases.  
  
Discussion: https://postgr.es/m/5b0d8e4f-f2a3-1305-d612-e00e35a7be66@qunar.com  

M contrib/ltree/expected/ltree.out
M contrib/ltree/ltree_op.c
M contrib/ltree/sql/ltree.sql
M doc/src/sgml/ltree.sgml

Fix inadequate buffer locking in FSM and VM page re-initialization.

commit   : 6d2d5ab173a9b4a131827313522451dff3fb4ac1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Jul 2018 11:52:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Jul 2018 11:52:50 -0400    

Click here for diff

When reading an existing FSM or VM page that was found to be corrupt by the  
buffer manager, the code applied PageInit() to reinitialize the page, but  
did so without any locking.  There is thus a hazard that two backends might  
concurrently do PageInit, which in itself would still be OK, but the slower  
one might then zero over subsequent data changes applied by the faster one.  
Even that is unlikely to be fatal; but it's not desirable, so add locking  
to prevent it.  
  
This does not add any locking overhead in the normal code path where the  
page is OK.  It's not immediately obvious that that's safe, but I believe  
it is, for reasons explained in the added comments.  
  
Problem noted by R P Asim.  It's been like this for a long time, so  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CANXE4Te4G0TGq6cr0-TvwP0H4BNiK_-hB5gHe8mF+nz0mcYfMQ@mail.gmail.com  

M src/backend/access/heap/visibilitymap.c
M src/backend/storage/freespace/freespace.c

docs: Remove “New” description of the libpqxx interface

commit   : a6bbf1c31a80abcddaad24015bbf24b340fdbea2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 13 Jul 2018 11:16:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 13 Jul 2018 11:16:55 -0400    

Click here for diff

Backpatch-through: 9.3  

M doc/src/sgml/external-projects.sgml

Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.

commit   : f38d5a27373ff281f2eb62a156d058e57cfac96e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jul 2018 12:28:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jul 2018 12:28:43 -0400    

Click here for diff

Explain that you can use any integer expression for the "count" in  
pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only  
allow a constant.  
  
Remove the duplicate version of this para under MOVE.  I don't see  
a good reason to maintain two identical paras when we just said that  
MOVE works exactly like FETCH.  
  
Per Pavel Stehule, though I didn't use his text.  
  
Discussion: https://postgr.es/m/CAFj8pRAcvSXcNdUGx43bOK1e3NNPbQny7neoTLN42af+8MYWEA@mail.gmail.com  

M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/ref/fetch.sgml

Make logical WAL sender report streaming state appropriately

commit   : 98e2c298c2f5fef158a6bf0d543a84098671ae7d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Jul 2018 10:20:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Jul 2018 10:20:27 +0900    

Click here for diff

WAL senders sending logically-decoded data fail to properly report in  
"streaming" state when starting up, hence as long as one extra record is  
not replayed, such WAL senders would remain in a "catchup" state, which  
is inconsistent with the physical cousin.  
  
This can be easily reproduced by for example using pg_recvlogical and  
restarting the upstream server.  The TAP tests have been slightly  
modified to detect the failure and strengthened so as future tests also  
make sure that a node is in streaming state when waiting for its  
catchup.  
  
Backpatch down to 9.4 where this code has been introduced.  
  
Reported-by: Sawada Masahiko  
Author: Simon Riggs, Sawada Masahiko  
Reviewed-by: Petr Jelinek, Michael Paquier, Vaishnavi Prabakaran  
Discussion: https://postgr.es/m/CAD21AoB2ZbCCqOx=bgKMcLrAvs1V0ZMqzs7wBTuDySezTGtMZA@mail.gmail.com  

M src/backend/replication/walsender.c

Avoid emitting a bogus WAL record when recycling an all-zero btree page.

commit   : d80ec868fa3aa61a8f2566ec0244c45a87a62e20    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2018 19:26:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2018 19:26:19 -0400    

Click here for diff

Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for  
a page that it was about to recycle.  However, it failed to distinguish  
all-zero pages from dead pages, which is important because only the  
latter have valid btpo.xact values, or indeed any special space at all.  
Recycling an all-zero page with XLogStandbyInfoActive() enabled therefore  
led to an Assert failure, or to emission of a WAL record containing a  
bogus cutoff XID, which might lead to unnecessary query cancellations  
on hot standby servers.  
  
Per reports from Antonin Houska and 自己.  Amit Kapila was first to  
propose this fix, and Robert Haas, myself, and Kyotaro Horiguchi  
reviewed it at various times.  
  
This is an old bug, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/2628.1474272158@localhost  
Discussion: https://postgr.es/m/48875502.f4a0.1635f0c27b0.Coremail.zoulx1982@163.com  

M src/backend/access/nbtree/nbtpage.c

Prevent accidental linking of system-supplied copies of libpq.so etc.

commit   : dd4e836748cec3e361e3b52243137960557a000d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2018 17:23:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2018 17:23:32 -0400    

Click here for diff

Back-patch commit dddfc4cb2, which broke LDFLAGS and related Makefile  
variables into two parts, one for within-build-tree library references and  
one for external libraries, to ensure that the order of -L flags has all  
of the former before all of the latter.  This turns out to fix a problem  
recently noted on buildfarm member peripatus, that we attempted to  
incorporate code from libpgport.a into a shared library.  That will fail on  
platforms that are sticky about putting non-PIC code into shared libraries.  
(It's quite surprising we hadn't seen such failures before, since the code  
in question has been like that for a long time.)  
  
I think that peripatus' problem could have been fixed with just a subset  
of this patch; but since the previous issue of accidentally linking to the  
wrong copy of a Postgres shlib seems likely to bite people in the field,  
let's just back-patch the whole change.  Now that commit dddfc4cb2 has  
survived some beta testing, I'm less afraid to back-patch it than I was  
at the time.  
  
This also fixes undesired inclusion of "-DFRONTEND" in pg_config's CPPFLAGS  
output (in 9.6 and up) and undesired inclusion of "-L../../src/common" in  
its LDFLAGS output (in all supported branches).  
  
Back-patch to v10 and older branches; this is already in v11.  
  
Discussion: https://postgr.es/m/20180704234304.bq2dxispefl65odz@ler-imac.local  

M contrib/dblink/Makefile
M contrib/oid2name/Makefile
M contrib/pgbench/Makefile
M contrib/postgres_fdw/Makefile
M contrib/spi/Makefile
M contrib/vacuumlo/Makefile
M src/Makefile.global.in
M src/Makefile.shlib
M src/backend/replication/libpqwalreceiver/Makefile
M src/bin/pg_basebackup/Makefile
M src/bin/pg_config/Makefile
M src/bin/pg_ctl/Makefile
M src/interfaces/ecpg/compatlib/Makefile
M src/interfaces/ecpg/ecpglib/Makefile
M src/interfaces/ecpg/pgtypeslib/Makefile
M src/interfaces/ecpg/test/Makefile.regress
M src/interfaces/ecpg/test/compat_informix/Makefile
M src/interfaces/libpq/test/Makefile
M src/makefiles/pgxs.mk
M src/test/examples/Makefile

Prevent references to invalid relation pages after fresh promotion

commit   : f352f43d3f10a8491035cc3ccd6f85aa6215aead    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Jul 2018 10:47:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Jul 2018 10:47:50 +0900    

Click here for diff

If a standby crashes after promotion before having completed its first  
post-recovery checkpoint, then the minimal recovery point which marks  
the LSN position where the cluster is able to reach consistency may be  
set to a position older than the first end-of-recovery checkpoint while  
all the WAL available should be replayed.  This leads to the instance  
thinking that it contains inconsistent pages, causing a PANIC and a hard  
instance crash even if all the WAL available has not been replayed for  
certain sets of records replayed.  When in crash recovery,  
minRecoveryPoint is expected to always be set to InvalidXLogRecPtr,  
which forces the recovery to replay all the WAL available, so this  
commit makes sure that the local copy of minRecoveryPoint from the  
control file is initialized properly and stays as it is while crash  
recovery is performed.  Once switching to archive recovery or if crash  
recovery finishes, then the local copy minRecoveryPoint can be safely  
updated.  
  
Pavan Deolasee has reported and diagnosed the failure in the first  
place, and the base fix idea to rely on the local copy of  
minRecoveryPoint comes from Kyotaro Horiguchi, which has been expanded  
into a full-fledged patch by me.  The test included in this commit has  
been written by Álvaro Herrera and Pavan Deolasee, which I have modified  
to make it faster and more reliable with sleep phases.  
  
Backpatch down to all supported versions where the bug appears, aka 9.3  
which is where the end-of-recovery checkpoint is not run by the startup  
process anymore.  The test gets easily supported down to 10, still it  
has been tested on all branches.  
  
Reported-by: Pavan Deolasee  
Diagnosed-by: Pavan Deolasee  
Reviewed-by: Pavan Deolasee, Kyotaro Horiguchi  
Author: Michael Paquier, Kyotaro Horiguchi, Pavan Deolasee, Álvaro  
Herrera  
Discussion: https://postgr.es/m/CABOikdPOewjNL=05K5CbNMxnNtXnQjhTx2F--4p4ruorCjukbA@mail.gmail.com  

M src/backend/access/transam/xlog.c

Check for interrupts inside the nbtree page deletion code.

commit   : 8c8c9f37c283292b0505c6337f96662ce6f5be2b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Jul 2018 14:53:53 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Jul 2018 14:53:53 -0700    

Click here for diff

When deleting pages the nbtree code has to walk through siblings of a  
tree node. When those sibling links are corrupted that can lead to  
endless loops - which are currently not interruptible.  This is  
especially problematic if autovacuum is repeatedly blocked on such  
indexes, as it can be hard to get out of that situation without  
resorting to single user mode.  
  
Thus add interrupt checks to appropriate places in such  
loops. Unfortunately in one of the cases it's it's not easy to do so.  
  
Between 9.3 and 9.4 the page deletion (and page split) code changed  
significantly. Before it was significantly less robust against  
interruptions. Therefore don't backpatch to 9.3.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20180627191629.wkunw2qbibnvlz53@alap3.anarazel.de  
Backpatch: 9.4-  

M src/backend/access/nbtree/nbtpage.c

Improve the performance of relation deletes during recovery.

commit   : 62c2fe6446801d9a7e8169544666416f5536c2bb    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Jul 2018 02:21:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Jul 2018 02:21:15 +0900    

Click here for diff

When multiple relations are deleted at the same transaction,  
the files of those relations are deleted by one call to smgrdounlinkall(),  
which leads to scan whole shared_buffers only one time. OTOH,  
previously, during recovery, smgrdounlink() (not smgrdounlinkall()) was  
called for each file to delete, which led to scan shared_buffers  
multiple times. Obviously this could cause to increase the WAL replay  
time very much especially when shared_buffers was huge.  
  
To alleviate this situation, this commit changes the recovery so that  
it also calls smgrdounlinkall() only one time to delete multiple  
relation files.  
  
This is just fix for oversight of commit 279628a0a7, not new feature.  
So, per discussion on pgsql-hackers, we concluded to backpatch this  
to all supported versions.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier, Andres Freund, Thomas Munro, Kyotaro Horiguchi, Takayuki Tsunakawa  
Discussion: https://postgr.es/m/CAHGQGwHVQkdfDqtvGVkty+19cQakAydXn1etGND3X0PHbZ3+6w@mail.gmail.com  

M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/storage/smgr/md.c
M src/include/storage/smgr.h

Fix libpq example programs

commit   : 2a4dca949109dae3b95c5f4d55462fd4e6673310    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 1 Jul 2018 14:06:40 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 1 Jul 2018 14:06:40 +0200    

Click here for diff

When these programs call pg_catalog.set_config, they need to check for  
PGRES_TUPLES_OK instead of PGRES_COMMAND_OK.  Fix for  
5770172cb0c9df9e6ce27c507b449557e5b45124.  
  
Reported-by: Ideriha, Takeshi <ideriha.takeshi@jp.fujitsu.com>  

M doc/src/sgml/libpq.sgml
M doc/src/sgml/lobj.sgml
M src/test/examples/testlibpq.c
M src/test/examples/testlibpq2.c
M src/test/examples/testlibpq4.c
M src/test/examples/testlo.c
M src/test/examples/testlo64.c

Replace search.cpan.org with metacpan.org

commit   : f61a25727cd9246d749825cdaafa821b7ddbad7c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 29 Jun 2018 22:18:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 29 Jun 2018 22:18:24 +0900    

Click here for diff

search.cpan.org has been EOL'd, with metacpan.org being the official  
replacement to which URLs now redirect.  Update links to match the new  
URL. Also update links to CPAN to use https as it will redirect from  
http.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/B74C0219-6BA9-46E1-A524-5B9E8CD3BDB3@yesql.se  

M doc/src/sgml/acronyms.sgml
M doc/src/sgml/external-projects.sgml
M doc/src/sgml/install-windows.sgml

Fix “base” snapshot handling in logical decoding

commit   : 962313558f956e04e6871a96c57c2f1db3c685d1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Jun 2018 16:38:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Jun 2018 16:38:34 -0400    

Click here for diff

Two closely related bugs are fixed.  First, xmin of logical slots was  
advanced too early.  During xl_running_xacts processing, xmin of the  
slot was set to the oldest running xid in the record, but that's wrong:  
actually, snapshots which will be used for not-yet-replayed transactions  
might consider older txns as running too, so we need to keep xmin back  
for them.  The problem wasn't noticed earlier because DDL which allows  
to delete tuple (set xmax) while some another not-yet-committed  
transaction looks at it is pretty rare, if not unique: e.g. all forms of  
ALTER TABLE which change schema acquire ACCESS EXCLUSIVE lock  
conflicting with any inserts. The included test case (test_decoding's  
oldest_xmin) uses ALTER of a composite type, which doesn't have such  
interlocking.  
  
To deal with this, we must be able to quickly retrieve oldest xmin  
(oldest running xid among all assigned snapshots) from ReorderBuffer. To  
fix, add another list of ReorderBufferTXNs to the reorderbuffer, where  
transactions are sorted by base-snapshot-LSN.  This is slightly  
different from the existing (sorted by first-LSN) list, because a  
transaction can have an earlier LSN but a later Xmin, if its first  
record does not obtain an xmin (eg. xl_xact_assignment).  Note this new  
list doesn't fully replace the existing txn list: we still need that one  
to prevent WAL recycling.  
  
The second issue concerns SnapBuilder snapshots and subtransactions.  
SnapBuildDistributeNewCatalogSnapshot never assigned a snapshot to a  
transaction that is known to be a subtxn, which is good in the common  
case that the top-level transaction already has one (no point in doing  
so), but a bug otherwise.  To fix, arrange to transfer the snapshot from  
the subtxn to its top-level txn as soon as the kinship gets known.  
test_decoding's snapshot_transfer verifies this.  
  
Also, fix a minor memory leak: refcount of toplevel's old base snapshot  
was not decremented when the snapshot is transferred from child.  
  
Liberally sprinkle code comments, and rewrite a few existing ones.  This  
part is my (Álvaro's) contribution to this commit, as I had to write all  
those comments in order to understand the existing code and Arseny's  
patch.  
  
Reported-by: Arseny Sher <a.sher@postgrespro.ru>  
Diagnosed-by: Arseny Sher <a.sher@postgrespro.ru>  
Co-authored-by: Arseny Sher <a.sher@postgrespro.ru>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Antonin Houska <ah@cybertec.at>  
Discussion: https://postgr.es/m/87lgdyz1wj.fsf@ars-thinkpad  

M contrib/test_decoding/Makefile
A contrib/test_decoding/expected/oldest_xmin.out
A contrib/test_decoding/expected/snapshot_transfer.out
A contrib/test_decoding/specs/oldest_xmin.spec
A contrib/test_decoding/specs/snapshot_transfer.spec
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
M src/include/replication/reorderbuffer.h

commit   : 4765ac0570730c66fdeb2eb43b0b4e68653b4247    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 Jun 2018 00:45:21 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 Jun 2018 00:45:21 +0900    

Click here for diff

The backup history file has been no longer necessary for recovery  
since the version 9.0. It's now basically just for informational purpose.  
But previously the documentations still described that a recovery  
requests the backup history file to proceed. The commit fixes this  
documentation bug.  
  
Back-patch to all supported versions.  
  
Author: Yugo Nagata  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20180626174752.0ce505e3.nagata@sraoss.co.jp  

M doc/src/sgml/backup.sgml
M doc/src/sgml/high-availability.sgml

Add PGTYPESchar_free() to avoid cross-module problems on Windows.

commit   : db05d0b906be6dbf194ce594e0a0777ebdaf7e93    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 18 Jun 2018 18:33:53 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 18 Jun 2018 18:33:53 +1200    

Click here for diff

On Windows, it is sometimes important for corresponding malloc() and  
free() calls to be made from the same DLL, since some build options can  
result in multiple allocators being active at the same time.  For that  
reason we already provided PQfreemem().  This commit adds a similar  
function for freeing string results allocated by the pgtypes library.  
  
Author: Takayuki Tsunakawa  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8AD5D6%40G01JPEXMBYT05  

M doc/src/sgml/ecpg.sgml
M src/interfaces/ecpg/include/Makefile
A src/interfaces/ecpg/include/pgtypes.h
M src/interfaces/ecpg/include/pgtypes_date.h
M src/interfaces/ecpg/include/pgtypes_interval.h
M src/interfaces/ecpg/include/pgtypes_numeric.h
M src/interfaces/ecpg/include/pgtypes_timestamp.h
M src/interfaces/ecpg/pgtypeslib/common.c
M src/interfaces/ecpg/pgtypeslib/exports.txt
M src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-dt_test2.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c
M src/interfaces/ecpg/test/expected/preproc-outofscope.c
M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc
M src/interfaces/ecpg/test/pgtypeslib/dt_test2.pgc
M src/interfaces/ecpg/test/pgtypeslib/num_test.pgc
M src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc
M src/interfaces/ecpg/test/sql/sqlda.pgc

Move RecoveryLockList into a hash table.

commit   : c4ccbcc1a2a17d547537ccecd9e856cb083c2ff7    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 26 Jun 2018 18:23:36 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 26 Jun 2018 18:23:36 +1200    

Click here for diff

Standbys frequently need to release all locks held by a given xid.  
Instead of searching one big list linearly, let's create one list  
per xid and put them in a hash table, so we can find what we need  
in O(1) time.  
  
Earlier analysis and a prototype were done by David Rowley, though  
this isn't his patch.  
  
Back-patch all the way.  
  
Author: Thomas Munro  
Diagnosed-by: David Rowley, Andres Freund  
Reviewed-by: Andres Freund, Tom Lane, Robert Haas  
Discussion: https://postgr.es/m/CAEepm%3D1mL0KiQ2KJ4yuPpLGX94a4Ns_W6TL4EGRouxWibu56pA%40mail.gmail.com  
Discussion: https://postgr.es/m/CAKJS1f9vJ841HY%3DwonnLVbfkTWGYWdPN72VMxnArcGCjF3SywA%40mail.gmail.com  

M src/backend/storage/ipc/standby.c

Address set of issues with errno handling

commit   : 79b5b101f99238a3f3cac84e6323895db41d8410    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Jun 2018 10:30:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Jun 2018 10:30:59 +0900    

Click here for diff

System calls mixed up in error code paths are causing two issues which  
several code paths have not correctly handled:  
1) For write() calls, sometimes the system may return less bytes than  
what has been written without errno being set.  Some paths were careful  
enough to consider that case, and assumed that errno should be set to  
ENOSPC, other calls missed that.  
2) errno generated by a system call is overwritten by other system calls  
which may succeed once an error code path is taken, causing what is  
reported to the user to be incorrect.  
  
This patch uses the brute-force approach of correcting all those code  
paths.  Some refactoring could happen in the future, but this is let as  
future work, which is not targeted for back-branches anyway.  
  
Author: Michael Paquier  
Reviewed-by: Ashutosh Sharma  
Discussion: https://postgr.es/m/20180622061535.GD5215@paquier.xyz  

M src/backend/access/heap/rewriteheap.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xlog.c
M src/backend/replication/basebackup.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
M src/backend/replication/slot.c
M src/bin/pg_basebackup/receivelog.c

doc: adjust order of NUMERIC arguments to match syntax

commit   : 21ba0b442d0520fc856eaa608d839a64590afa31    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 24 Jun 2018 18:07:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 24 Jun 2018 18:07:00 -0400    

Click here for diff

Specifically, mention precision before scale  
  
Reported-by: claytonjsalem@gmail.com  
  
Discussion: https://postgr.es/m/152967566691.1268.1062965601465200209@wrigleys.postgresql.org  
  
Backpatch-through: 9.3  

M doc/src/sgml/datatype.sgml

doc: show how interval’s 3 unit buckets behave using EXTRACT()

commit   : e8616362da3419f81c802a665315c7b411eae2f4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Jun 2018 23:32:41 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Jun 2018 23:32:41 -0400    

Click here for diff

This clarifies when justify_days() and justify_hours() are useful.  
Paragraph moved too.  
  
Reported-by: vodevsh@gmail.com  
  
Discussion: https://postgr.es/m/152698651482.26744.15456677499485530703@wrigleys.postgresql.org  
  
Backpatch-through: 9.3  

M doc/src/sgml/datatype.sgml

Fix typo

commit   : af050c07b05fb495ffc194c8dad2f2966070e47b    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 16:07:07 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 16:07:07 +0200    

Click here for diff

Reported using the website comment form  

M doc/src/sgml/dml.sgml

doc: explain use of json_populate_record{set}()

commit   : 957b86a5abaffaf7709270332f24cad9ad3ee8ec    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Jun 2018 13:43:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Jun 2018 13:43:40 -0400    

Click here for diff

The set-returning nature of these functions make their use unclear. The  
modified paragraph was added in PG 9.4.  
  
Reported-by: yshaladi@denodo.com  
  
Discussion:  https://postgr.es/m/152571684246.9460.18059951267371255159@wrigleys.postgresql.org  
  
Backpatch-through: 9.4  

M doc/src/sgml/func.sgml

Use -Wno-format-truncation and -Wno-stringop-truncation, if available.

commit   : 817d605e411faacec09f2f95f9749f8a23eb83b1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 15:34:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 15:34:07 -0400    

Click here for diff

gcc 8 has started emitting some warnings that are largely useless for  
our purposes, particularly since they complain about code following  
the project-standard coding convention that path names are assumed  
to be shorter than MAXPGPATH.  Even if we make the effort to remove  
that assumption in some future release, the changes wouldn't get  
back-patched.  Hence, just suppress these warnings, on compilers that  
have these switches.  
  
Backpatch to all supported branches.  
  
Discussion: https://postgr.es/m/1524563856.26306.9.camel@gunduz.org  

M configure
M configure.in

Avoid unnecessary use of strncpy in a couple of places in ecpg.

commit   : cd56194d189dd616ad432110af2d8bf8dd533845    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 14:58:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 14:58:11 -0400    

Click here for diff

Use of strncpy with a length limit based on the source, rather than  
the destination, is non-idiomatic and draws warnings from gcc 8.  
Replace with memcpy, which does exactly the same thing in these cases,  
but with less chance for confusion.  
  
Backpatch to all supported branches.  
  
Discussion: https://postgr.es/m/21789.1529170195@sss.pgh.pa.us  

M src/interfaces/ecpg/ecpglib/descriptor.c
M src/interfaces/ecpg/pgtypeslib/common.c

Use snprintf not sprintf in pg_waldump’s timestamptz_to_str.

commit   : fd079dd0915a2005da2fbfd75fda1cc3611f3a2f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 14:45:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 14:45:47 -0400    

Click here for diff

This could only cause an issue if strftime returned a ridiculously  
long timezone name, which seems unlikely; and it wouldn't qualify  
as a security problem even then, since pg_waldump (nee pg_xlogdump)  
is a debug tool not part of the server.  But gcc 8 has started issuing  
warnings about it, so let's use snprintf and be safe.  
  
Backpatch to 9.3 where this code was added.  
  
Discussion: https://postgr.es/m/21789.1529170195@sss.pgh.pa.us  

M contrib/pg_xlogdump/compat.c

Fix bugs in vacuum of shared rels, by keeping their relcache entries current.

commit   : 817f9f9a8a1932a0cd8c6bc5c9d3e77f6a80e659    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 12 Jun 2018 11:13:22 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 12 Jun 2018 11:13:22 -0700    

Click here for diff

When vacuum processes a relation it uses the corresponding relcache  
entry's relfrozenxid / relminmxid as a cutoff for when to remove  
tuples etc. Unfortunately for nailed relations (i.e. critical system  
catalogs) bugs could frequently lead to the corresponding relcache  
entry being stale.  
  
This set of bugs could cause actual data corruption as vacuum would  
potentially not remove the correct row versions, potentially reviving  
them at a later point.  After 699bf7d05c some corruptions in this vein  
were prevented, but the additional error checks could also trigger  
spuriously. Examples of such errors are:  
  ERROR: found xmin ... from before relfrozenxid ...  
and  
  ERROR: found multixact ... from before relminmxid ...  
To be caused by this bug the errors have to occur on system catalog  
tables.  
  
The two bugs are:  
  
1) Invalidations for nailed relations were ignored, based on the  
   theory that the relcache entry for such tables doesn't  
   change. Which is largely true, except for fields like relfrozenxid  
   etc.  This means that changes to relations vacuumed in other  
   sessions weren't picked up by already existing sessions.  Luckily  
   autovacuum doesn't have particularly longrunning sessions.  
  
2) For shared *and* nailed relations, the shared relcache init file  
   was never invalidated while running.  That means that for such  
   tables (e.g. pg_authid, pg_database) it's not just already existing  
   sessions that are affected, but even new connections are as well.  
   That explains why the reports usually were about pg_authid et. al.  
  
To fix 1), revalidate the rd_rel portion of a relcache entry when  
invalid. This implies a bit of extra complexity to deal with  
bootstrapping, but it's not too bad.  The fix for 2) is simpler,  
simply always remove both the shared and local init files.  
  
Author: Andres Freund  
Reviewed-By: Alvaro Herrera  
Discussion:  
    https://postgr.es/m/20180525203736.crkbg36muzxrjj5e@alap3.anarazel.de  
    https://postgr.es/m/CAMa1XUhKSJd98JW4o9StWPrfS=11bPgG+_GDMxe25TvUY4Sugg@mail.gmail.com  
    https://postgr.es/m/CAKMFJucqbuoDRfxPDX39WhA3vJyxweRg_zDVXzncr6+5wOguWA@mail.gmail.com  
    https://postgr.es/m/CAGewt-ujGpMLQ09gXcUFMZaZsGJC98VXHEFbF-tpPB0fB13K+A@mail.gmail.com  
Backpatch: 9.3-  

M src/backend/utils/cache/inval.c
M src/backend/utils/cache/relcache.c

Fix grammar in REVOKE documentation

commit   : 25a85613b77b9c8b894be2a238ead3716f56a68c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 10 Jun 2018 22:44:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 10 Jun 2018 22:44:17 +0900    

Click here for diff

Reported-by: Erwin Brandstetter  

M doc/src/sgml/ref/revoke.sgml

Fix function code in error report

commit   : 5970bfb04eb5de1b0883b9cfd477baef8f070196    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 6 Jun 2018 14:46:53 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 6 Jun 2018 14:46:53 -0400    

Click here for diff

This bug causes a lseek() failure to be reported as a "could not open"  
failure in the error message, muddling bug reports.  I introduced this  
copy-and-pasteo in commit 78e122010422.  
  
Noticed while reviewing code for bug report #15221, from lily liang.  In  
version 10 the affected function is only used by multixact.c and  
commit_ts, and only in corner-case circumstances, neither of which are  
involved in the reported bug (a pg_subtrans failure.)  
  
Author: Álvaro Herrera  

M src/backend/access/transam/slru.c

doc: mark ‘replaceable’ parameter for backup program listing

commit   : 252d9c43427d38fbdc2abd2cc4d19982ec523545    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 28 May 2018 14:19:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 28 May 2018 14:19:45 -0400    

Click here for diff

Reported-by: Liudmila Mantrova  
  
Discussion: https://postgr.es/m/f3e2c0f5-5266-d626-58d7-b77e1b29d870@postgrespro.ru  
  
Author: Liudmila Mantrova  
  
Backpatch-through: 9.3  

M doc/src/sgml/backup.sgml

doc: adjust DECLARE docs to mention FOR UPDATE behavior

commit   : c5bc95da0aae12eb24722f5d89a966a38b556913    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 28 May 2018 13:16:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 28 May 2018 13:16:02 -0400    

Click here for diff

Reported-by: Peter Eisentraut  
  
Discussion: https://postgr.es/m/8dc63ba7-dc56-fc7c-fc16-4fae03e3bfe6@2ndquadrant.com  
  
Author: Peter Eisentraut, Tom Lane, me  
  
Backpatch-through: 9.3  

M doc/src/sgml/ref/declare.sgml

Fix misidentification of SQL statement type in plpgsql’s exec_stmt_execsql.

commit   : 98d522a1de1b6c90edabbbfda0cda734286edd03    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2018 14:31:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2018 14:31:07 -0400    

Click here for diff

To distinguish SQL statements that are INSERT/UPDATE/DELETE from other  
ones, exec_stmt_execsql looked at the post-rewrite form of the statement  
rather than the original.  This is problematic because it did that only  
during first execution of the statement (in a session), but the correct  
answer could change later due to addition or removal of DO INSTEAD rules  
during the session.  That could lead to an Assert failure, as reported  
by Tushar Ahuja and Robert Haas.  In non-assert builds, there's a hazard  
that we would fail to enforce STRICT behavior when we'd be expected to.  
That would happen if an initially present DO INSTEAD, that replaced the  
original statement with one of a different type, were removed; after that  
the statement should act "normally", including strictness enforcement, but  
it didn't.  (The converse case of enforcing strictness when we shouldn't  
doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the  
statement type would always lead to acting as though the statement returned  
zero rows, so that the strictness error could not fire.)  
  
To fix, inspect the original form of the statement not the post-rewrite  
form, making it valid to assume the answer can't change intra-session.  
This should lead to the same answer in every case except when there is a  
DO INSTEAD that changes the statement type; we will now set mod_stmt=true  
anyway, while we would not have done so before.  That breaks the Assert  
in the SPI_OK_REWRITTEN code path, which expected the latter behavior.  
It might be all right to assert mod_stmt rather than !mod_stmt there,  
but I'm not entirely convinced that that'd always hold, so just remove  
the assertion altogether.  
  
This has been broken for a long time, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/CA+TgmoZUrRN4xvZe_BbBn_Xp0BDwuMEue-0OyF0fJpfvU2Yc7Q@mail.gmail.com  

M src/pl/plpgsql/src/pl_exec.c

Remove incorrect statement about IPC configuration on OpenBSD

commit   : 54db851b77353482bfb75316faad0630e8c8477c    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 25 May 2018 13:59:50 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 25 May 2018 13:59:50 +0200    

Click here for diff

kern.ipc.shm_use_phys is not a sysctl on OpenBSD, and SEMMAP is not  
a kernel configuration option. These were probably copy pasteos from  
when the documentation had a single paragraph for *BSD.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  

M doc/src/sgml/runtime.sgml

Properly schema-qualify additional object types in getObjectDescription().

commit   : 8f2143bc8fe9df1262d6bb71064160a5763188cc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 12:07:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 12:07:41 -0400    

Click here for diff

Collations, conversions, extended statistics objects (in >= v10),  
and all four types of text search objects have schema-qualified names.  
getObjectDescription() ignored that and would emit just the base name of  
the object, potentially producing wrong or at least highly misleading  
output.  Fix it to add the schema name whenever the object is not "visible"  
in the current search path, as is the rule for other schema-qualifiable  
object types.  
  
Although in common situations the output won't change, this seems to me  
(tgl) to be a bug worthy of back-patching, hence do so.  
  
Kyotaro Horiguchi, per a complaint from me  
  
Discussion: https://postgr.es/m/20180522.182020.114074746.horiguchi.kyotaro@lab.ntt.co.jp  

M src/backend/catalog/objectaddress.c
M src/test/regress/expected/alter_generic.out
M src/test/regress/expected/alter_table.out

Fix simple_prompt() to disable echo on Windows when stdin != terminal.

commit   : 09fb2d5d3b8f616a81a8b5087e2543143b337c36    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 May 2018 19:04:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 May 2018 19:04:34 -0400    

Click here for diff

If echo = false, simple_prompt() is supposed to prevent echoing the  
input (for password input).  However, the Windows implementation applied  
the mode change to STD_INPUT_HANDLE.  That would not have the desired  
effect if stdin isn't actually the terminal, for instance if the user  
is piping something into psql.  Fix it to apply the mode change to  
the correct input file, so that passwords do not echo in such cases.  
  
In passing, shorten and de-uglify this code by using #elif rather than  
an #if nest and removing some duplicated code.  
  
Back-patch to all supported versions.  To simplify that, also back-patch  
the portions of commit 9daec77e1 that got rid of an unnecessary  
malloc/free in the same area.  
  
Matthew Stickney (cosmetic changes by me)  
  
Discussion: https://postgr.es/m/502a1fff-862b-da52-1031-f68df6ed5a2d@gmail.com  

M src/port/sprompt.c

Widen COPY FROM’s current-line-number counter from 32 to 64 bits.

commit   : d25714d0a344544b4f9d5cee9b83e197e9210cb0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 May 2018 13:32:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 May 2018 13:32:52 -0400    

Click here for diff

Because the code for the HEADER option skips a line when this counter  
is zero, a very long COPY FROM WITH HEADER operation would drop a line  
every 2^32 lines.  A lesser but still unfortunate problem is that errors  
would show a wrong input line number for errors occurring beyond the  
2^31'st input line.  While such large input streams seemed impractical  
when this code was first written, they're not any more.  Widening the  
counter (and some associated variables) to uint64 should be enough to  
prevent problems for the foreseeable future.  
  
David Rowley  
  
Discussion: https://postgr.es/m/CAKJS1f88yh-6wwEfO6QLEEvH3BEugOq2QX1TOja0vCauoynmOQ@mail.gmail.com  

M src/backend/commands/copy.c

Fix SQL:2008 FETCH FIRST syntax to allow parameters.

commit   : 769e6fcd1a350ad3720030bcfa00d8c7ec9cf970    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Mon, 21 May 2018 17:02:17 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Mon, 21 May 2018 17:02:17 +0100    

Click here for diff

OFFSET <x> ROWS FETCH FIRST <y> ROWS ONLY syntax is supposed to accept  
<simple value specification>, which includes parameters as well as  
literals. When this syntax was added all those years ago, it was done  
inconsistently, with <x> and <y> being different subsets of the  
standard syntax.  
  
Rectify that by making <x> and <y> accept the same thing, and allowing  
either a (signed) numeric literal or a c_expr there, which allows for  
parameters, variables, and parenthesized arbitrary expressions.  
  
Per bug #15200 from Lukas Eder.  
  
Backpatch all the way, since this has been broken from the start.  
  
Discussion: https://postgr.es/m/877enz476l.fsf@news-spur.riddles.org.uk  
Discussion: http://postgr.es/m/152647780335.27204.16895288237122418685@wrigleys.postgresql.org  

M doc/src/sgml/ref/select.sgml
M src/backend/parser/gram.y

Fix unsafe usage of strerror(errno) within ereport().

commit   : 5517367e978b29dedb1ca0e84a0285b8f9446fde    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 00:32:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 00:32:28 -0400    

Click here for diff

This is the converse of the unsafe-usage-of-%m problem: the reason  
ereport/elog provide that format code is mainly to dodge the hazard  
of errno getting changed before control reaches functions within the  
arguments of the macro.  I only found one instance of this hazard,  
but it's been there since 9.4 :-(.  

M src/backend/libpq/auth.c

printf(“%lf”) is not portable, so omit the “l”.

commit   : e52cabff7054005d2f7157c236d996dcd79baf5c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 May 2018 11:40:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 May 2018 11:40:54 -0400    

Click here for diff

The "l" (ell) width spec means something in the corresponding scanf usage,  
but not here.  While modern POSIX says that applying "l" to "f" and other  
floating format specs is a no-op, SUSv2 says it's undefined.  Buildfarm  
experience says that some old compilers emit warnings about it, and at  
least one old stdio implementation (mingw's "ANSI" option) actually  
produces wrong answers and/or crashes.  
  
Discussion: https://postgr.es/m/21670.1526769114@sss.pgh.pa.us  
Discussion: https://postgr.es/m/c085e1da-0d64-1c15-242d-c921f32e0d5c@dunslane.net  

M doc/src/sgml/ecpg.sgml
M src/interfaces/ecpg/test/compat_informix/sqlda.pgc
M src/interfaces/ecpg/test/expected/compat_informix-sqlda.c
M src/interfaces/ecpg/test/expected/preproc-outofscope.c
M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/preproc/outofscope.pgc
M src/interfaces/ecpg/test/sql/sqlda.pgc

Support platforms where strtoll/strtoull are spelled strtoll/strtoull.

commit   : 8109f201da7745477519e0e151b900a6aeca6e69    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 May 2018 14:22:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 May 2018 14:22:19 -0400    

Click here for diff

Ancient HPUX, for one, does this.  We hadn't noticed due to the lack  
of regression tests that required a working strtoll.  
  
(I was slightly tempted to remove the other historical spelling,  
strto[u]q, since it seems we have no buildfarm members testing that case.  
But I refrained.)  
  
Discussion: https://postgr.es/m/151935568942.1461.14623890240535309745@wrigleys.postgresql.org  

M configure
M configure.in
M src/include/c.h
M src/include/pg_config.h.in
M src/include/pg_config.h.win32

Arrange to supply declarations for strtoll/strtoull if needed.

commit   : 023aa76e19529bf3f00f1815262fc78186c01636    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 22:42:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 22:42:10 -0400    

Click here for diff

Buildfarm member dromedary is still unhappy about the recently-added  
ecpg "long long" tests.  The reason turns out to be that it includes  
"-ansi" in its CFLAGS, and in their infinite wisdom Apple have decided  
to hide the declarations of strtoll/strtoull in C89-compliant builds.  
(I find it pretty curious that they hide those function declarations  
when you can nonetheless declare a "long long" variable, but anyway  
that is their behavior, both on dromedary's obsolete macOS version and  
the newest and shiniest.)  As a result, gcc assumes these functions  
return "int", leading naturally to wrong results.  
  
(Looking at dromedary's past build results, it's evident that this  
problem also breaks pg_strtouint64() on 32-bit platforms; but we  
evidently have no regression tests that exercise that function with  
values above 32 bits.)  
  
To fix, supply declarations for these functions when the platform  
provides the functions but not the declarations, using the same type  
of mechanism as we use for some other similar cases.  
  
Discussion: https://postgr.es/m/151935568942.1461.14623890240535309745@wrigleys.postgresql.org  

M configure
M configure.in
M src/include/c.h
M src/include/pg_config.h.in
M src/include/pg_config.h.win32

Hot-fix ecpg regression test for missing ecpg_config.h inclusion.

commit   : 54ae787ca732f7627ca2e5e000b21d42aec1c17b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 19:03:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 19:03:32 -0400    

Click here for diff

I don't think this is really the best long-term answer, and in  
particular it doesn't fix the pre-existing hazard in sqltypes.h.  
But for the moment let's just try to make the buildfarm green again.  
  
Discussion: https://postgr.es/m/151935568942.1461.14623890240535309745@wrigleys.postgresql.org  

M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/sql/sqlda.pgc

Add some test coverage for ecpg’s “long long” support.

commit   : e75c832b29b1ffbf1737915be9d9940162524fef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 13:04:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 13:04:59 -0400    

Click here for diff

This will only actually exercise the "long long" code paths on platforms  
where "long" is 32 bits --- otherwise, the SQL bigint type maps to  
plain "long", and we will test that code path instead.  But that's  
probably sufficient coverage, and anyway we weren't testing either  
code path before.  
  
Dang Minh Huong, tweaked a bit by me  
  
Discussion: https://postgr.es/m/151935568942.1461.14623890240535309745@wrigleys.postgresql.org  

M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/expected/sql-sqlda.stderr
M src/interfaces/ecpg/test/expected/sql-sqlda.stdout
M src/interfaces/ecpg/test/sql/sqlda.pgc

Recognize that MSVC can support strtoll() and strtoull().

commit   : 385f4acbf824f520287f20373ebae4713382a568    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 12:52:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 12:52:28 -0400    

Click here for diff

This is needed for full support of "long long" variables in ecpg, but  
the previous patch for bug #15080 (commits 51057feaa et al) missed it.  
In MSVC versions where the functions don't exist under those names,  
we can nonetheless use _strtoi64() and _strtoui64().  
  
Like the previous patch, back-patch all the way.  
  
Dang Minh Huong  
  
Discussion: https://postgr.es/m/151935568942.1461.14623890240535309745@wrigleys.postgresql.org  

M src/include/pg_config.h.win32

Fix error message on short read of pg_control

commit   : b5f096d50bee5c20023ed05390fdc52aa44a1404    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 18 May 2018 17:53:19 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 18 May 2018 17:53:19 +0200    

Click here for diff

Instead of saying "error: success", indicate that we got a working read  
but it was too short.  

M src/backend/access/transam/xlog.c

Fix misprocessing of equivalence classes involving record_eq().

commit   : 62e0020ad4914899d416edaa7d676499afcdc113    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 May 2018 13:46:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 May 2018 13:46:09 -0400    

Click here for diff

canonicalize_ec_expression() is supposed to agree with coerce_type() as to  
whether a RelabelType should be inserted to make a subexpression be valid  
input for the operators of a given opclass.  However, it did the wrong  
thing with named-composite-type inputs to record_eq(): it put in a  
RelabelType to RECORDOID, which the parser doesn't.  In some cases this was  
harmless because all code paths involving a particular equivalence class  
did the same thing, but in other cases this would result in failing to  
recognize a composite-type expression as being a member of an equivalence  
class that it actually is a member of.  The most obvious bad effect was to  
fail to recognize that an index on a composite column could provide the  
sort order needed for a mergejoin on that column, as reported by Teodor  
Sigaev.  I think there might be other, subtler, cases that result in  
misoptimization.  It also seems possible that an unwanted RelabelType  
would sometimes get into an emitted plan --- but because record_eq and  
friends don't examine the declared type of their input expressions, that  
would not create any visible problems.  
  
To fix, just treat RECORDOID as if it were a polymorphic type, which in  
some sense it is.  We might want to consider formalizing that a bit more  
someday, but for the moment this seems to be the only place where an  
IsPolymorphicType() test ought to include RECORDOID as well.  
  
This has been broken for a long time, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/a6b22369-e3bf-4d49-f59d-0c41d3551e81@sigaev.ru  

M src/backend/optimizer/path/equivclass.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql

Update time zone data files to tzdata release 2018e.

commit   : 32453bc5af8dbd9101abbdcd07d954c1f9318d9c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 May 2018 13:55:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 May 2018 13:55:27 -0400    

Click here for diff

DST law changes in North Korea.  Redefinition of "daylight savings" in  
Ireland, as well as for some past years in Namibia and Czechoslovakia.  
Additional historical corrections for Czechoslovakia.  
  
With this change, the IANA database models Irish timekeeping as following  
"standard time" in summer, and "daylight savings" in winter, so that the  
daylight savings offset is one hour behind standard time not one hour  
ahead.  This does not change their UTC offset (+1:00 in summer, 0:00 in  
winter) nor their timezone abbreviations (IST in summer, GMT in winter),  
though now "IST" is more correctly read as "Irish Standard Time" not "Irish  
Summer Time".  However, the "is_dst" column in the pg_timezone_names view  
will now be true in winter and false in summer for the Europe/Dublin zone.  
  
Similar changes were made for Namibia between 1994 and 2017, and for  
Czechoslovakia between 1946 and 1947.  
  
So far as I can find, no Postgres internal logic cares about which way  
tm_isdst is reported; in particular, since commit b2cbced9e we do not  
rely on it to decide how to interpret ambiguous timestamps during DST  
transitions.  So I don't think this change will affect any Postgres  
behavior other than the timezone-view outputs.  
  
Discussion: https://postgr.es/m/30996.1525445902@sss.pgh.pa.us  

M src/backend/utils/adt/datetime.c
M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Europe.txt

Improve inefficient regexes in vacuumdb TAP test.

commit   : 3d48654017aa7fc2c261a5d4d01025306fa188d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 May 2018 20:17:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 May 2018 20:17:43 -0400    

Click here for diff

The regexes used in 102_vacuumdb_stages.pl to check the postmaster log  
for expected output contained several places with ".*.*", which is  
underdetermined and can cause exponential runtime growth in Perl's regex  
matcher (since it's not bright enough not to waste time seeing whether  
different splits of the same substring would allow a match).  We were  
fortunate that the amount of text in the postmaster log was generally not  
enough to make the runtime go to the moon; although commit 6271fceb8 had  
been on the hairy edge of an obvious problem, thanks to its increasing the  
default log verbosity to DEBUG1.  Experimentation shows that anyone who  
tried to run this test case with an even higher log verbosity would have  
been in for serious pain.  But even at default logging level, fixing this  
saves several hundred ms on my workstation, more on slower buildfarm  
members.  
  
Remove the extra ".*"s, restoring more-or-less-linear matching speed.  
Back-patch to 9.4 where the test case was added, mostly in case anyone  
tries to do related debugging in a back branch.  
  
Discussion: https://postgr.es/m/32459.1525657786@sss.pgh.pa.us  

M src/bin/scripts/t/102_vacuumdb_stages.pl