PostgreSQL 11.1 commit log

Last-minute updates for release notes.

commit   : d06fe6ce2c79420fd19ac89ace81b66579f08493    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Nov 2018 18:56:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Nov 2018 18:56:26 -0500    

Click here for diff

Add entries for v11 changes that went in post-stamping, but before  
the final wrap.  

M doc/src/sgml/release-11.sgml

Disable recheck_on_update optimization to avoid crashes.

commit   : 05f84605dbeb9cf8279a157234b24bbb706c5256    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Nov 2018 18:33:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Nov 2018 18:33:15 -0500    

Click here for diff

The code added by commit c203d6cf8 causes a crash in at least one case,  
where a potentially-optimizable expression index has a storage type  
different from the input data type.  A cursory code review turned up  
numerous other problems that seem impractical to fix on short notice.  
  
Andres argued for revert of that patch some time ago, and if additional  
senior committers had been paying attention, that's likely what would  
have happened, but we were not :-(  
  
At this point we can't just revert, at least not in v11, because that would  
mean an ABI break for code touching relcache entries.  And we should not  
remove the (also buggy) support for the recheck_on_update index reloption,  
since it might already be used in some databases in the field.  So this  
patch just does the as-little-invasive-as-possible measure of disabling  
the feature as though recheck_on_update were forced off for all indexes.  
I also removed the related regression tests (which would otherwise fail)  
and the user-facing documentation of the reloption.  
  
We should undertake a more thorough code cleanup if the patch can't be  
fixed, but not under the extreme time pressure of being already overdue  
for 11.1 release.  
  
Per report from Ondřej Bouda and subsequent private discussion among  
pgsql-release.  
  
Discussion: https://postgr.es/m/20181106185255.776mstcyehnc63ty@alvherre.pgsql  

M doc/src/sgml/ref/create_index.sgml
M doc/src/sgml/release-11.sgml
M src/backend/utils/cache/relcache.c
D src/test/regress/expected/func_index.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
D src/test/regress/sql/func_index.sql

GUC: adjust effective_cache_size SQL descriptions

commit   : 1833d23690cc39e9b7a9d05a317b00203533d33f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Nov 2018 13:40:02 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Nov 2018 13:40:02 -0500    

Click here for diff

Follow on patch for commit 3e0f1a4741f564c1a2fa6e944729d6967355d8c7.  
  
Reported-by: Peter Eisentraut  
  
Discussion: https://postgr.es/m/369ec766-b947-51bd-4dad-6fb9e026439f@2ndquadrant.com  
  
Backpatch-through: 9.4  

M src/backend/utils/misc/guc.c

Rename rbtree.c functions to use “rbt” prefix not “rb” prefix.

commit   : 1f28ec6be27085819a6adfa96ba305bb4ee47f4c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Nov 2018 13:25:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Nov 2018 13:25:24 -0500    

Click here for diff

The "rb" prefix is used by Ruby, so that our existing code results  
in name collisions that break plruby.  We discussed ways to prevent  
that by adjusting dynamic linker options, but it seems that at best  
we'd move the pain to other cases.  Renaming to avoid the collision  
is the only portable fix anyway.  Fortunately, our rbtree code is  
not (yet?) widely used --- in core, there's only a single usage  
in GIN --- so it seems likely that we can get away with a rename.  
  
I chose to do this basically as s/rb/rbt/g, except for places where  
there already was a "t" after "rb".  The patch could have been made  
smaller by only touching linker-visible symbols, but it would have  
resulted in oddly inconsistent-looking code.  Better to make it look  
like "rbt" was the plan all along.  
  
Back-patch to v10.  The rbtree.c code exists back to 9.5, but  
rb_iterate() which is the actual immediate source of pain was added  
in v10, so it seems like changing the names before that would have  
more risk than benefit.  
  
Per report from Pavel Raiskup.  
  
Discussion: https://postgr.es/m/4738198.8KVIIDhgEB@nb.usersys.redhat.com  

M src/backend/access/gin/ginbulk.c
M src/backend/lib/rbtree.c
M src/include/access/gin_private.h
M src/include/lib/rbtree.h
M src/test/modules/test_rbtree/test_rbtree.c

Stamp 11.1.

commit   : fef63a80bba7048b5a7e642cc5e6a5b9d25589a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Nov 2018 16:43:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Nov 2018 16:43:09 -0500    

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

Last-minute updates for release notes.

commit   : 1623740d841fde74dd492fef87d48f0100bdcce8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Nov 2018 16:07:06 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Nov 2018 16:07:06 -0500    

Click here for diff

I removed the item about the pg_stat_statements change from  
release-11.sgml, as part of a sweep to delete items already committed  
in 11.0; but actually we'd best keep it to ensure that people who've  
pg_upgraded their databases will take the requisite action.  Also make  
said action more visible by making it into its own para.  Noted by  
Jonathan Katz.  

M doc/src/sgml/release-10.sgml
M doc/src/sgml/release-11.sgml

Fix copy-paste error in errhint() introduced in 691d79a07933.

commit   : 9c7049ef4f9c6f22033b4b7a532e105301eb81a4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Nov 2018 12:02:25 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Nov 2018 12:02:25 -0800    

Click here for diff

Reported-By: Petr Jelinek  
Discussion: https://postgr.es/m/c95a620b-34f0-7930-aeb5-f7ab804f26cb@2ndquadrant.com  
Backpatch: 9.4-, like the previous commit  

M src/backend/replication/slot.c

Last-minute updates for release notes.

commit   : 2da33cbd52aaf5cbc4bc6c4e42e8879ee75a859d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Nov 2018 10:48:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Nov 2018 10:48:23 -0500    

Click here for diff

Security: CVE-2018-16850  

M doc/src/sgml/release-10.sgml
M doc/src/sgml/release-11.sgml

Translation updates

commit   : af5ab115bce2cacf2bc8e8d5a9674b07c7e89272    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Nov 2018 14:43:50 +0100    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Nov 2018 14:43:50 +0100    

Click here for diff

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

M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/backend/po/tr.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/it.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/it.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_basebackup/po/tr.po
M src/bin/pg_controldata/po/it.po
M src/bin/pg_ctl/po/it.po
M src/bin/pg_ctl/po/tr.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/it.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_rewind/po/it.po
M src/bin/pg_rewind/po/tr.po
M src/bin/pg_upgrade/po/tr.po
M src/bin/pg_verify_checksums/po/ru.po
M src/bin/pg_verify_checksums/po/tr.po
M src/bin/psql/po/it.po
M src/bin/psql/po/tr.po
M src/bin/scripts/po/it.po
M src/bin/scripts/po/tr.po
M src/interfaces/ecpg/preproc/po/it.po
M src/interfaces/libpq/po/it.po
M src/interfaces/libpq/po/tr.po
M src/pl/plperl/po/it.po
M src/pl/plpgsql/src/po/it.po
M src/pl/plpython/po/it.po
M src/pl/plpython/po/tr.po

Block creation of partitions with open references to its parent

commit   : 7c222d5e56cca4e2081dc7841ed118a97666cb8e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Nov 2018 11:04:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Nov 2018 11:04:14 +0900    

Click here for diff

When a partition is created as part of a trigger processing, it is  
possible that the partition which just gets created changes the  
properties of the table the executor of the ongoing command relies on,  
causing a subsequent crash.  This has been found possible when for  
example using a BEFORE INSERT which creates a new partition for a  
partitioned table being inserted to.  
  
Any attempt to do so is blocked when working on a partition, with  
regression tests added for both CREATE TABLE PARTITION OF and ALTER  
TABLE ATTACH PARTITION.  
  
Reported-by: Dmitry Shalashov  
Author: Amit Langote  
Reviewed-by: Michael Paquier, Tom Lane  
Discussion: https://postgr.es/m/15437-3fe01ee66bd1bae1@postgresql.org  
Backpatch-through: 10  

M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/create_table.out
M src/test/regress/sql/alter_table.sql
M src/test/regress/sql/create_table.sql

Ignore partitioned tables when processing ON COMMIT DELETE ROWS

commit   : 948af52324fb0ab635ebb1c1379980dbfc589aba    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Nov 2018 09:15:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Nov 2018 09:15:08 +0900    

Click here for diff

Those tables have no physical storage, making this option unusable with  
partition trees as at commit time an actual truncation was attempted.  
There are still issues with the way ON COMMIT actions are done when  
mixing several action types, however this impacts as well inheritance  
trees, so this issue will be dealt with later.  
  
Reported-by: Rajkumar Raghuwanshi  
Author: Amit Langote  
Reviewed-by: Michael Paquier, Tom Lane  
Discussion: https://postgr.es/m/CAKcux6mhgcjSiB_egqEAEFgX462QZtncU8QCAJ2HZwM-wWGVew@mail.gmail.com  

M src/backend/catalog/heap.c
M src/test/regress/expected/temp.out
M src/test/regress/sql/temp.sql

Release notes for 11.1, 10.6, 9.6.11, 9.5.15, 9.4.20, 9.3.25.

commit   : 84010b9989d92bd7fb4a4b7c0e96dbe81ef101f4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Nov 2018 16:57:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Nov 2018 16:57:14 -0500    

Click here for diff

M doc/src/sgml/release-10.sgml
M doc/src/sgml/release-11.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
M doc/src/sgml/release-9.5.sgml
M doc/src/sgml/release-9.6.sgml

Fix ExecuteCallStmt to not scribble on the passed-in parse tree.

commit   : d358da81414abc57ef44dfd45dfedc3d443e5bd5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Nov 2018 14:50:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Nov 2018 14:50:55 -0500    

Click here for diff

Modifying the parse tree at execution time is, or at least ought to be,  
verboten.  It seems quite difficult to actually cause a crash this way  
in v11 (although you can exhibit it pretty easily in HEAD by messing  
with plan_cache_mode).  Nonetheless, it's risky, so fix and back-patch.  
  
Discussion: https://postgr.es/m/13789.1541359611@sss.pgh.pa.us  

M src/backend/commands/functioncmds.c

Fix bugs in plpgsql’s handling of CALL argument lists.

commit   : 4b0c3712c530e3be92682099f56dbe0b08d802c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Nov 2018 13:25:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Nov 2018 13:25:39 -0500    

Click here for diff

exec_stmt_call() tried to extract information out of a CALL statement's  
argument list without using expand_function_arguments(), apparently in  
the hope of saving a few nanoseconds by not processing defaulted  
arguments.  It got that quite wrong though, leading to crashes with  
named arguments, as well as failure to enforce writability of the  
argument for a defaulted INOUT parameter.  Fix and simplify the logic  
by using expand_function_arguments() before examining the list.  
  
Also, move the argument-examination to just after producing the CALL  
command's plan, before invoking the called procedure.  This ensures  
that we'll track possible changes in the procedure's argument list  
correctly, and avoids a hazard of the plan cache being flushed while  
the procedure executes.  
  
Also fix assorted falsehoods and omissions in associated documentation.  
  
Per bug #15477 from Alexey Stepanov.  
  
Patch by me, with some help from Pavel Stehule.  Back-patch to v11.  
  
Discussion: https://postgr.es/m/15477-86075b1d1d319e0a@postgresql.org  
Discussion: https://postgr.es/m/CAFj8pRA6UsujpTs9Sdwmk-R6yQykPx46wgjj+YZ7zxm4onrDyw@mail.gmail.com  

M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/ref/call.sgml
M src/pl/plpgsql/src/expected/plpgsql_call.out
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/sql/plpgsql_call.sql

Fix unused-variable warning.

commit   : 6f4e01c7d289ee39d08317f12ef979805bcbba00    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Nov 2018 11:20:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Nov 2018 11:20:59 -0500    

Click here for diff

Discussion: https://postgr.es/m/CAMkU=1xTHkS6d0iptCWykHc1Xrh3LBic_gZDo3JzDYru815fLQ@mail.gmail.com  

M src/backend/executor/execExpr.c

Prevent generating EEOP_AGG_STRICT_INPUT_CHECK operations when nargs == 0.

commit   : 6eb31cedb316d59bf9c63658868ff0fcddcc085a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Nov 2018 15:55:23 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Nov 2018 15:55:23 -0700    

Click here for diff

This only became a problem with 4c640f4f38, which didn't synchronize  
the value agg_strict_input_check.nargs is set to, with the guard  
condition for emitting the operation.  
  
Besides such instructions being unnecessary overhead, currently the  
LLVM JIT provider doesn't support them. It seems more sensible to  
avoid generating such instruction than supporting them. Add assertions  
to make it easier to debug a potential further occurance.  
  
Discussion: https://postgr.es/m/2a505161-2727-2473-7c46-591ed108ac52@email.cz  
Backpatch: 11-, like 4c640f4f38.  

M src/backend/executor/execExpr.c
M src/backend/jit/llvm/llvmjit_expr.c

Fix STRICT check for strict aggregates with NULL ORDER BY columns.

commit   : fd59b29c873915064f7af6a33c968c97e0d59166    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Nov 2018 14:35:23 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Nov 2018 14:35:23 -0700    

Click here for diff

I (Andres) broke this unintentionally in 69c3936a14, by checking  
strictness for all input expressions computed for an aggregate, rather  
than just the input for the aggregate transition function.  
  
Reported-By: Ondřej Bouda  
Bisected-By: Tom Lane  
Diagnosed-By: Andrew Gierth  
Discussion: https://postgr.es/m/2a505161-2727-2473-7c46-591ed108ac52@email.cz  
Backpatch: 11-, like 69c3936a14  

M src/backend/executor/execExpr.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql

Make ts_locale.c’s character-type functions cope with UTF-16.

commit   : bf4a9562e8b93ebb69715c7dbdfc90dd6945e369    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Nov 2018 13:56:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Nov 2018 13:56:10 -0400    

Click here for diff

On Windows, in UTF8 database encoding, what char2wchar() produces is  
UTF16 not UTF32, ie, characters above U+FFFF will be represented by  
surrogate pairs.  t_isdigit() and siblings did not account for this  
and failed to provide a large enough result buffer.  That in turn  
led to bogus "invalid multibyte character for locale" errors, because  
contrary to what you might think from char2wchar()'s documentation,  
its Windows code path doesn't cope sanely with buffer overflow.  
  
The solution for t_isdigit() and siblings is pretty clear: provide  
a 3-wchar_t result buffer not 2.  
  
char2wchar() also needs some work to provide more consistent, and more  
accurately documented, buffer overrun behavior.  But that's a bigger job  
and it doesn't actually have any immediate payoff, so leave it for later.  
  
Per bug #15476 from Kenji Uno, who deserves credit for identifying the  
cause of the problem.  Back-patch to all active branches.  
  
Discussion: https://postgr.es/m/15476-4314f480acf0f114@postgresql.org  

M src/backend/tsearch/ts_locale.c

Fix tablespace handling for partitioned indexes

commit   : 33e6c34c32677a168bee4bc6c335aa8d73211a56    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 3 Nov 2018 13:23:37 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 3 Nov 2018 13:23:37 -0300    

Click here for diff

When creating partitioned indexes, the tablespace was not being saved  
for the parent index. This meant that subsequently created partitions  
would not use the right tablespace for their indexes.  
  
ALTER INDEX SET TABLESPACE and ALTER INDEX ALL IN TABLESPACE raised  
errors when tried; fix them too.  This requires bespoke code for  
ATExecCmd() that applies to the special case when the tablespace move is  
just a catalog change.  
  
Discussion: https://postgr.es/m/20181102003138.uxpaca6qfxzskepi@alvherre.pgsql  

M src/backend/catalog/heap.c
M src/backend/commands/tablecmds.c
M src/test/regress/input/tablespace.source
M src/test/regress/output/tablespace.source

Remove extra word from create sub docs

commit   : 0e88ba1fe1e02086e718982a86c94c3c366c9d62    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sat, 3 Nov 2018 12:22:01 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sat, 3 Nov 2018 12:22:01 -0400    

Click here for diff

Improve the documentation in the CREATE SUBSCRIPTION command a bit by  
removing an extraneous word and spelling out 'information'.  

M doc/src/sgml/ref/create_subscription.sgml

Yet further rethinking of build changes for macOS Mojave.

commit   : df1d749a7bdae302d593b6710a6219c682236137    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Nov 2018 18:54:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Nov 2018 18:54:00 -0400    

Click here for diff

The solution arrived at in commit e74dd00f5 presumes that the compiler  
has a suitable default -isysroot setting ... but further experience  
shows that in many combinations of macOS version, XCode version, Xcode  
command line tools version, and phase of the moon, Apple's compiler  
will *not* supply a default -isysroot value.  
  
We could potentially go back to the approach used in commit 68fc227dd,  
but I don't have a lot of faith in the reliability or life expectancy of  
that either.  Let's just revert to the approach already shipped in 11.0,  
namely specifying an -isysroot switch globally.  As a partial response to  
the concerns raised by Jakob Egger, adjust the contents of Makefile.global  
to look like  
  
CPPFLAGS = -isysroot $(PG_SYSROOT) ...  
PG_SYSROOT = /path/to/sysroot  
  
This allows overriding the sysroot path at build time in a relatively  
painless way.  
  
Add documentation to installation.sgml about how to use the PG_SYSROOT  
option.  I also took the opportunity to document how to work around  
macOS's "System Integrity Protection" feature.  
  
As before, back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us  

M configure
M configure.in
M doc/src/sgml/installation.sgml
M src/Makefile.global.in
M src/template/darwin

Fix NULL handling in multi-batch Parallel Hash Left Join.

commit   : fd6449aa38759cc35c32c1d5bf87c516ba6385c8    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 3 Nov 2018 11:08:03 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 3 Nov 2018 11:08:03 +1300    

Click here for diff

NULL keys in left joins were skipped when building batch files.  
Repair, by making the keep_nulls argument to ExecHashGetHashValue()  
depend on whether this is a left outer join, as we do in other  
paths.  
  
Bug #15475.  Thinko in 1804284042e.  Back-patch to 11.  
  
Reported-by: Paul Schaap  
Diagnosed-by: Andrew Gierth  
Dicussion: https://postgr.es/m/15475-11a7a783fed72a36%40postgresql.org  

M src/backend/executor/nodeHashjoin.c

docs: adjust simpler language for NULL return from ANY/ALL

commit   : ca49b5ca5af35bc1ee199105cec94fb86ad9a59b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Nov 2018 13:05:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Nov 2018 13:05:30 -0400    

Click here for diff

Adjustment to commit 8610c973ddf1cbf0befc1369d2cf0d56c0efcd0a.  
  
Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/17406.1541168421@sss.pgh.pa.us  
  
Backpatch-through: 9.3  

M doc/src/sgml/func.sgml

GUC: adjust effective_cache_size docs and SQL description

commit   : 23524418e578085cb37bfb064ddd4bc1172c069e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Nov 2018 09:11:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Nov 2018 09:11:00 -0400    

Click here for diff

Clarify that effective_cache_size is both kernel buffers and shared  
buffers.  
  
Reported-by: nat@makarevitch.org  
  
Discussion: https://postgr.es/m/153685164808.22334.15432535018443165207@wrigleys.postgresql.org  
  
Backpatch-through: 9.3  

M doc/src/sgml/config.sgml
M src/backend/utils/misc/guc.c

Fix some spelling errors in the documentation

commit   : 708b96d56aee3cee830623f26c231e371fda19e4    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 2 Nov 2018 13:55:57 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 2 Nov 2018 13:55:57 +0100    

Click here for diff

Author: Daniel Gustafsson <daniel@yesql.se>  

M doc/src/sgml/libpq.sgml
M doc/src/sgml/lobj.sgml
M doc/src/sgml/logical-replication.sgml

doc: use simpler language for NULL return from ANY/ALL

commit   : 61abff11f29e98abf8badfeca86cf05650911998    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Nov 2018 08:54:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Nov 2018 08:54:34 -0400    

Click here for diff

Previously the combination of "does not return" and "any row" caused  
ambiguity.  
  
Reported-by: KES <kes-kes@yandex.ru>  
  
Discussion: https://postgr.es/m/153701242703.22334.1476830122267077397@wrigleys.postgresql.org  
  
Reviewed-by: David G. Johnston  
  
Backpatch-through: 9.3  

M doc/src/sgml/func.sgml

Fix error message typo introduced 691d79a07933.

commit   : 0446551fc114aff1b820a006d5a3eb185b6f931a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 1 Nov 2018 10:44:29 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 1 Nov 2018 10:44:29 -0700    

Click here for diff

Reported-By: Michael Paquier  
Discussion: https://postgr.es/m/20181101003405.GB1727@paquier.xyz  
Backpatch: 9.4-, like the previous commit  

M src/backend/replication/slot.c

Adjust trace_sort log messages.

commit   : 886319d71bd5c0ba18c9b46a1e3765d88f5ed0e7    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 1 Nov 2018 09:18:55 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 1 Nov 2018 09:18:55 -0700    

Click here for diff

The project message style guide dictates: "When citing the name of an  
object, state what kind of object it is".  The parallel CREATE INDEX  
patch added a worker number to most of the trace_sort messages within  
tuplesort.c without specifying the object type.  Bring these messages  
into compliance with the style guide.  
  
We're still treating a leader or serial Tuplesortstate as having worker  
number -1.  trace_sort is a developer option, and these two cases are  
highly comparable, so this seems appropriate.  
  
Per complaint from Tom Lane.  
  
Discussion: https://postgr.es/m/8330.1540831863@sss.pgh.pa.us  
Backpatch: 11-, where parallel CREATE INDEX was introduced.  

M src/backend/utils/sort/tuplesort.c

Disallow starting server with insufficient wal_level for existing slot.

commit   : c33a01c7979dc267c81ece612af783ecacf22bc0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 31 Oct 2018 14:47:41 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 31 Oct 2018 14:47:41 -0700    

Click here for diff

Previously it was possible to create a slot, change wal_level, and  
restart, even if the new wal_level was insufficient for the  
slot. That's a problem for both logical and physical slots, because  
the necessary WAL records are not generated.  
  
This removes a few tests in newer versions that, somewhat  
inexplicably, whether restarting with a too low wal_level worked (a  
buggy behaviour!).  
  
Reported-By: Joshua D. Drake  
Author: Andres Freund  
Discussion: https://postgr.es/m/20181029191304.lbsmhshkyymhw22w@alap3.anarazel.de  
Backpatch: 9.4-, where replication slots where introduced  

M src/backend/replication/logical/logical.c
M src/backend/replication/slot.c
M src/test/recovery/t/006_logical_decoding.pl

Fix memory leak in repeated SPGIST index scans.

commit   : 2493e2c2d167ce7ad7d034c7c7de17d79e806c7a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Oct 2018 17:04:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Oct 2018 17:04:42 -0400    

Click here for diff

spgendscan neglected to pfree all the memory allocated by spgbeginscan.  
It's possible to get away with that in most normal queries, since the  
memory is allocated in the executor's per-query context which is about  
to get deleted anyway; but it causes severe memory leakage during  
creation or filling of large exclusion-constraint indexes.  
  
Also, document that amendscan is supposed to free what ambeginscan  
allocates.  The docs' lack of clarity on that point probably caused this  
bug to begin with.  (There is discussion of changing that API spec going  
forward, but I don't think it'd be appropriate for the back branches.)  
  
Per report from Bruno Wolff.  It's been like this since the beginning,  
so back-patch to all active branches.  
  
In HEAD, also fix an independent leak caused by commit 2a6368343  
(allocating memory during spgrescan instead of spgbeginscan, which  
might be all right if it got cleaned up, but it didn't).  And do a bit  
of code beautification on that commit, too.  
  
Discussion: https://postgr.es/m/20181024012314.GA27428@wolff.to  

M doc/src/sgml/indexam.sgml
M src/backend/access/spgist/spgscan.c

Sync our copy of the timezone library with IANA release tzcode2018g.

commit   : f107c33461e5372fa2257c09bcdb173c9d47dc03    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Oct 2018 09:47:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Oct 2018 09:47:53 -0400    

Click here for diff

This patch absorbs an upstream fix to "zic" for a recently-introduced  
bug that made it output data that some 32-bit clients couldn't read.  
Given the current source data, the bug only manifests in zones with  
leap seconds, which we don't generate, so that there's no actual  
change in our installed timezone data files from this.  Still, in  
case somebody uses our copy of "zic" to do something else, it seems  
best to apply the fix promptly.  
  
Also, update the README's notes about converting upstream code to  
our conventions.  

M src/timezone/README
M src/timezone/zic.c

Update time zone data files to tzdata release 2018g.

commit   : 58c45fdaa82fb37f1a4788df8d908c0f159b9c88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Oct 2018 08:35:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Oct 2018 08:35:50 -0400    

Click here for diff

DST law changes in Morocco (with, effectively, zero notice).  
Historical corrections for Hawaii.  

M src/timezone/data/tzdata.zi

Fix interaction of CASE and ArrayCoerceExpr.

commit   : 2bd6dcdeff09f6c3853d847b7516c9d51646716d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Oct 2018 15:26:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Oct 2018 15:26:11 -0400    

Click here for diff

An array-type coercion appearing within a CASE that has a constant  
(after const-folding) test expression was mangled by the planner, causing  
all the elements of the resulting array to be equal to the coerced value  
of the CASE's test expression.  This is my oversight in commit c12d570fa:  
that changed ArrayCoerceExpr to use a subexpression involving a  
CaseTestExpr, and I didn't notice that eval_const_expressions needed an  
adjustment to keep from folding such a CaseTestExpr to a constant when  
it's inside a suitable CASE.  
  
This is another in what's getting to be a depressingly long line of bugs  
associated with misidentification of the referent of a CaseTestExpr.  
We're overdue to redesign that mechanism; but any such fix is unlikely  
to be back-patchable into v11.  As a stopgap, fix eval_const_expressions  
to do what it must here.  Also add a bunch of comments pointing out the  
restrictions and assumptions that are needed to make this work at all.  
  
Also fix a related oversight: contain_context_dependent_node() was not  
aware of the relationship of ArrayCoerceExpr to CaseTestExpr.  That was  
somewhat fail-soft, in that the outcome of a wrong answer would be to  
prevent optimizations that could have been made, but let's fix it while  
we're at it.  
  
Per bug #15471 from Matt Williams.  Back-patch to v11 where the faulty  
logic came in.  
  
Discussion: https://postgr.es/m/15471-1117f49271989bad@postgresql.org  

M src/backend/executor/execExpr.c
M src/backend/optimizer/util/clauses.c
M src/backend/parser/parse_coerce.c
M src/backend/parser/parse_target.c
M src/include/nodes/primnodes.h
M src/test/regress/expected/case.out
M src/test/regress/sql/case.sql

Fix missing whitespace in pg_dump ref page

commit   : b5f1717ef54868d34e9f588aa20adc3e2ea72c8b    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 29 Oct 2018 12:34:49 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 29 Oct 2018 12:34:49 +0100    

Click here for diff

Author: Daniel Gustafsson <daniel@yesql.se>  

M doc/src/sgml/ref/pg_dump.sgml

pg_restore: Augment documentation for -N option

commit   : 29cdf02e3fb7afb3f26a81d95bf74d846e8a60b8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 29 Oct 2018 11:31:43 +0100    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 29 Oct 2018 11:31:43 +0100    

Click here for diff

This was forgotten when the option was added.  
  
Author: Michael Banck <michael.banck@credativ.de>  

M src/bin/pg_dump/pg_restore.c

Remove incorrect comment in dshash.c.

commit   : c653cb27b41eb1632e6d88a3efad482a11e45ee2    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 29 Oct 2018 12:57:55 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 29 Oct 2018 12:57:55 +1300    

Click here for diff

Back-patch to 11.  
  
Author: Antonin Houska  
Discussion: https://postgr.es/m/8726.1540553521%40localhost  

M src/backend/lib/dshash.c

Fix perl searchpath for modern perl for MSVC tools

commit   : 8cb5e67d1067579436cc6434235121b4f6f8f35b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 28 Oct 2018 12:22:32 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 28 Oct 2018 12:22:32 -0400    

Click here for diff

Modern versions of perl no longer include the current directory in the  
perl searchpath, as it's insecure. Instead of adding the current  
directory, we get around the problem by adding the directory where the  
script lives.  
  
Problem noted by Victor Wagner.  
  
Solution adapted from buildfarm client code.  
  
Backpatch to all live versions.  

M src/tools/msvc/install.pl
M src/tools/msvc/mkvcbuild.pl
M src/tools/msvc/vcregress.pl

Add tab completion of EXECUTE FUNCTION for CREATE TRIGGER in psql

commit   : fdf5eade96267d86af9efaf9213f5b3624e02354    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 26 Oct 2018 23:36:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 26 Oct 2018 23:36:40 +0900    

Click here for diff

The change to accept EXECUTE FUNCTION as well as EXECUTE PROCEDURE in  
CREATE TRIGGER (added by 0a63f99) forgot to tell psql's tab completion  
system about this.  
  
This change is version-aware, with FUNCTION being selected automatically  
instead of PROCEDURE depending on the backend version, PROCEDURE being  
an historical grammar kept for compatibility and considered as  
deprecated in v11.  
  
Author: Dagfinn Ilmari Mannsåker  
Reviewed-by: Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/d8jmur4q4yc.fsf@dalvik.ping.uio.no  

M src/bin/psql/tab-complete.c

Fix typo in regression test comment

commit   : ef4583238b9ceaca728a27aea711a5f467dc49d5    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Oct 2018 19:39:50 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Oct 2018 19:39:50 -0400    

Click here for diff

per Michael Banck  

M src/test/regress/expected/fast_default.out
M src/test/regress/sql/fast_default.sql

Correctly set t_self for heap tuples in expand_tuple

commit   : 372102b81dd0096764b712deffab00732f3c9d80    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Oct 2018 10:45:34 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Oct 2018 10:45:34 -0400    

Click here for diff

Commit 16828d5c0 incorrectly set an invalid pointer for t_self for heap  
tuples. This patch correctly copies it from the source tuple, and  
includes a regression test that relies on it being set correctly.  
  
Backpatch to release 11.  
  
Fixes bug #15448 reported by Tillmann Schulz  
  
Diagnosis and test case by Amit Langote  

M src/backend/access/common/heaptuple.c
M src/test/regress/expected/fast_default.out
M src/test/regress/sql/fast_default.sql

List wait events in alphabetical order in documentation

commit   : 374fe86a8fdd543a7eb11c68ac8c19eff29640d3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Oct 2018 17:02:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Oct 2018 17:02:45 +0900    

Click here for diff

Keeping all those entries in order helps the user looking at the  
documentation in finding them.  
  
Author: Michael Paquier, Kuntal Ghosh  
Discussion: https://postgr.es/m/20181024002539.GI1658@paquier.xy  

M doc/src/sgml/monitoring.sgml

Fix description of pg_class.relispartition in documentation

commit   : d5845b283d773287054758bb971b72d14267e9ed    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Oct 2018 15:39:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Oct 2018 15:39:32 +0900    

Click here for diff

This missed the fact that indexes can be partitions since 11.  
  
Author: Michael Paquier  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/20181022031212.GF14282@paquier.xyz  

M doc/src/sgml/catalogs.sgml

Fix some grammar errors in bloom.sgml

commit   : 33df118a73c099e4acd5d3244b2975468cc4a5c8    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 22 Oct 2018 00:23:26 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 22 Oct 2018 00:23:26 +0300    

Click here for diff

Discussion: https://postgr.es/m/CAEepm%3D3sijpGr8tXdyz-7EJJZfhQHABPKEQ29gpnb7-XSy%2B%3D5A%40mail.gmail.com  
Reported-by: Thomas Munro  
Backpatch-through: 9.6  

M doc/src/sgml/bloom.sgml

Lower privilege level of programs calling regression_main

commit   : a0a8671a61ae05315d32c1fc41969f0bfc8969b6    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 20 Oct 2018 09:02:36 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 20 Oct 2018 09:02:36 -0400    

Click here for diff

On Windows this mean that the regression tests can now safely and  
successfully run as Administrator, which is useful in situations like  
Appveyor. Elsewhere it's a no-op.  
  
Backpatch to 9.5 - this is harder in earlier branches and not worth the  
trouble.  
  
Discussion: https://postgr.es/m/650b0c29-9578-8571-b1d2-550d7f89f307@2ndQuadrant.com  

M src/test/regress/pg_regress.c

Client-side fixes for delayed NOTIFY receipt.

commit   : d30d27a52818ac863ba91bf9342fc9e8d466e30a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2018 22:22:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2018 22:22:57 -0400    

Click here for diff

PQnotifies() is defined to just process already-read data, not try to read  
any more from the socket.  (This is a debatable decision, perhaps, but I'm  
hesitant to change longstanding library behavior.)  The documentation has  
long recommended calling PQconsumeInput() before PQnotifies() to ensure  
that any already-arrived message would get absorbed and processed.  
However, psql did not get that memo, which explains why it's not very  
reliable about reporting notifications promptly.  
  
Also, most (not quite all) callers called PQconsumeInput() just once before  
a PQnotifies() loop.  Taking this recommendation seriously implies that we  
should do PQconsumeInput() before each call.  This is more important now  
that we have "payload" strings in notification messages than it was before;  
that increases the probability of having more than one packet's worth  
of notify messages.  Hence, adjust code as well as documentation examples  
to do it like that.  
  
Back-patch to 9.5 to match related server fixes.  In principle we could  
probably go back further with these changes, but given lack of field  
complaints I doubt it's worthwhile.  
  
Discussion: https://postgr.es/m/CAOYf6ec-TmRYjKBXLLaGaB-jrd=mjG1Hzn1a1wufUAR39PQYhw@mail.gmail.com  

M doc/src/sgml/libpq.sgml
M src/bin/psql/common.c
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/libpq/fe-exec.c
M src/test/examples/testlibpq2.c

Server-side fix for delayed NOTIFY and SIGTERM processing.

commit   : 7aaeb7b45ac7944ae09fcc9d3a2b58d2fdbefa87    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2018 21:39:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2018 21:39:21 -0400    

Click here for diff

Commit 4f85fde8e introduced some code that was meant to ensure that we'd  
process cancel, die, sinval catchup, and notify interrupts while waiting  
for client input.  But there was a flaw: it supposed that the process  
latch would be set upon arrival at secure_read() if any such interrupt  
was pending.  In reality, we might well have cleared the process latch  
at some earlier point while those flags remained set -- particularly  
notifyInterruptPending, which can't be handled as long as we're within  
a transaction.  
  
To fix the NOTIFY case, also attempt to process signals (except  
ProcDiePending) before trying to read.  
  
Also, if we see that ProcDiePending is set before we read, forcibly set the  
process latch to ensure that we will handle that signal promptly if no data  
is available.  I also made it set the process latch on the way out, in case  
there is similar logic elsewhere.  (It remains true that we won't service  
ProcDiePending here unless we need to wait for input.)  
  
The code for handling ProcDiePending during a write needs those changes,  
too.  
  
Also be a little more careful about when to reset whereToSendOutput,  
and improve related comments.  
  
Back-patch to 9.5 where this code was added.  I'm not entirely convinced  
that older branches don't have similar issues, but the complaint at hand  
is just about the >= 9.5 code.  
  
Jeff Janes and Tom Lane  
  
Discussion: https://postgr.es/m/CAOYf6ec-TmRYjKBXLLaGaB-jrd=mjG1Hzn1a1wufUAR39PQYhw@mail.gmail.com  

M src/backend/libpq/be-secure.c
M src/backend/tcop/postgres.c

Sync our copy of the timezone library with IANA release tzcode2018f.

commit   : 9892c180c99cba0f5657069e433d036f76b73bf3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2018 19:36:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2018 19:36:34 -0400    

Click here for diff

About half of this is purely cosmetic changes to reduce the diff between  
our code and theirs, like inserting "const" markers where they have them.  
  
The other half is tracking actual code changes in zic.c and localtime.c.  
I don't think any of these represent near-term compatibility hazards, but  
it seems best to stay up to date.  
  
I also fixed longstanding bugs in our code for producing the  
known_abbrevs.txt list, which by chance hadn't been exposed before,  
but which resulted in some garbage output after applying the upstream  
changes in zic.c.  Notably, because upstream removed their old phony  
transitions at the Big Bang, it's now necessary to cope with TZif files  
containing no DST transition times at all.  

M src/timezone/README
M src/timezone/localtime.c
M src/timezone/pgtz.h
M src/timezone/private.h
M src/timezone/strftime.c
M src/timezone/tzfile.h
M src/timezone/zic.c

Update time zone data files to tzdata release 2018f.

commit   : d2259c26b323e22d78c85d4012796bbc73597a5c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2018 17:01:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2018 17:01:34 -0400    

Click here for diff

DST law changes in Chile, Fiji, and Russia (Volgograd).  
Historical corrections for China, Japan, Macau, and North Korea.  
  
Note: like the previous tzdata update, this involves a depressingly  
large amount of semantically-meaningless churn in tzdata.zi.  That  
is a consequence of upstream's data compression method assigning  
unstable abbreviations to DST rulesets.  I complained about that  
to them last time, and this version now uses an assignment method  
that pays some heed to not changing abbreviations unnecessarily.  
So hopefully, that'll be better going forward.  

M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/America.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Pacific.txt

Use whitelist to choose files scanned with pg_verify_checksums

commit   : cc7f27eae888234d2fda9e0eaadbeb33a48cd274    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Oct 2018 22:44:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Oct 2018 22:44:12 +0900    

Click here for diff

The original implementation of pg_verify_checksums used a blacklist to  
decide which files should be skipped for scanning as they do not include  
data checksums, like pg_internal.init or pg_control.  However, this  
missed two things:  
- Some files are created within builds of EXEC_BACKEND and these were  
not listed, causing failures on Windows.  
- Extensions may create custom files in data folders, causing the tool  
to equally fail.  
  
This commit switches to a whitelist-like method instead by checking if  
the files to scan are authorized relation files.  This is close to a  
reverse-engineering of what is defined in relpath.c in charge of  
building the relation paths, and we could consider refactoring what this  
patch does so as all routines are in a single place.  This is left for  
later.  
  
This is based on a suggestion from Andres Freund.  TAP tests are updated  
so as multiple file patterns are tested.  The bug has been spotted by  
various buildfarm members as a result of b34e84f which has introduced  
the TAP tests of pg_verify_checksums.  
  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan, Michael Banck  
Discussion: https://postgr.es/m/20181012005614.GC26424@paquier.xyz  
Backpatch-through: 11  

M src/bin/pg_verify_checksums/pg_verify_checksums.c

Add missing quote_identifier calls for CREATE TRIGGER … REFERENCING.

commit   : 06292bb949e555f34edde7603237194a7daac942    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2018 00:50:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2018 00:50:16 -0400    

Click here for diff

Mixed-case names for transition tables weren't dumped correctly.  
Oversight in commit 8c48375e5, per bug #15440 from Karl Czajkowski.  
  
In passing, I couldn't resist a bit of code beautification.  
  
Back-patch to v10 where this was introduced.  
  
Discussion: https://postgr.es/m/15440-02d1468e94d63d76@postgresql.org  

M src/backend/utils/adt/ruleutils.c

Still further rethinking of build changes for macOS Mojave.

commit   : d1e869d1ef1c7a7665721fadf0140dad49151ca9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Oct 2018 14:55:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Oct 2018 14:55:23 -0400    

Click here for diff

To avoid the sorts of problems complained of by Jakob Egger, it'd be  
best if configure didn't emit any references to the sysroot path at all.  
In the case of PL/Tcl, we can do that just by keeping our hands off the  
TCL_INCLUDE_SPEC string altogether.  In the case of PL/Perl, we need to  
substitute -iwithsysroot for -I in the compile commands, which is easily  
handled if we change to using a configure output variable that includes  
the switch not only the directory name.  Since PL/Tcl and PL/Python  
already do it like that, this seems like good consistency cleanup anyway.  
  
Hence, this replaces the advice given to Perl-related extensions in commit  
5e2217131; instead of writing "-I$(perl_archlibexp)/CORE", they should  
just write "$(perl_includespec)".  (The old way continues to work, but not  
on recent macOS.)  
  
It's still the case that configure needs to be aware of the sysroot  
path internally, but that's cleaner than what we had before.  
  
As before, back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us  

M configure
M configure.in
M contrib/hstore_plperl/Makefile
M contrib/jsonb_plperl/Makefile
M src/Makefile.global.in
M src/pl/plperl/GNUmakefile
M src/template/darwin

Fix minor bug in isolationtester.

commit   : 0a21c6d9e512ad981273b74b61187ec6063de243    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Oct 2018 15:06:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Oct 2018 15:06:38 -0400    

Click here for diff

If the lock wait query failed, isolationtester would report the  
PQerrorMessage from some other connection, meaning there would be  
no message or an unrelated one.  This seems like a pretty unlikely  
occurrence, but if it did happen, this bug could make it really  
difficult/confusing to figure out what happened.  That seems to  
justify patching all the way back.  
  
In passing, clean up another place where the "wrong" conn was used  
for an error report.  That one's not actually buggy because it's  
a different alias for the same connection, but it's still confusing  
to the reader.  

M src/test/isolation/isolationtester.c

Improve tzparse’s handling of TZDEFRULES (“posixrules”) zone data.

commit   : db4f9c0258be90133af7240e12d925a490a30eb9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Oct 2018 12:26:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Oct 2018 12:26:48 -0400    

Click here for diff

In the IANA timezone code, tzparse() always tries to load the zone  
file named by TZDEFRULES ("posixrules").  Previously, we'd hacked  
that logic to skip the load in the "lastditch" code path, which we use  
only to initialize the default "GMT" zone during GUC initialization.  
That's critical for a couple of reasons: since we do not support leap  
seconds, we *must not* allow "GMT" to have leap seconds, and since this  
case runs before the GUC subsystem is fully alive, we'd really rather  
not take the risk of pg_open_tzfile throwing any errors.  
  
However, that still left the code reading TZDEFRULES on every other  
call, something we'd noticed to the extent of having added code to cache  
the result so it was only done once per process not a lot of times.  
Andres Freund complained about the static data space used up for the  
cache; but as long as the logic was like this, there was no point in  
trying to get rid of that space.  
  
We can improve matters by looking a bit more closely at what the IANA  
code actually needs the TZDEFRULES data for.  One thing it does is  
that if "posixrules" is a leap-second-aware zone, the leap-second  
behavior will be absorbed into every POSIX-style zone specification.  
However, that's a behavior we'd really prefer to do without, since  
for our purposes the end effect is to render every POSIX-style zone  
name unsupported.  Otherwise, the TZDEFRULES data is used only if  
the POSIX zone name specifies DST but doesn't include a transition  
date rule (e.g., "EST5EDT" rather than "EST5EDT,M3.2.0,M11.1.0").  
That is a minority case for our purposes --- in particular, it  
never happens when tzload() invokes tzparse() to interpret a  
transition date rule string found in a tzdata zone file.  
  
Hence, if we legislate that we're going to ignore leap-second data  
from "posixrules", we can postpone the TZDEFRULES load into the path  
where we actually need to substitute for a missing date rule string.  
That means it will never happen at all in common scenarios, making it  
reasonable to dynamically allocate the cache space when it does happen.  
Even when the data is already loaded, this saves some cycles in the  
common code path since we avoid a memcpy of 23KB or so.  And, IMO at  
least, this is a less ugly hack on the IANA logic than what we had  
before, since it's not messing with the lastditch-vs-regular code paths.  
  
Back-patch to all supported branches, not so much because this is a  
critical change as that I want to keep all our copies of the IANA  
timezone code in sync.  
  
Discussion: https://postgr.es/m/20181015200754.7y7zfuzsoux2c4ya@alap3.anarazel.de  

M src/timezone/README
M src/timezone/localtime.c

Back off using -isysroot on Darwin.

commit   : 1a69f738d25f878bf3b6b5415ab08b7ef48b7568    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Oct 2018 16:27:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Oct 2018 16:27:15 -0400    

Click here for diff

Rethink the solution applied in commit 5e2217131 to get PL/Tcl to  
build on macOS Mojave.  I feared that adding -isysroot globally might  
have undesirable consequences, and sure enough Jakob Egger reported  
one: it complicates building extensions with a different Xcode version  
than was used for the core server.  (I find that a risky proposition  
in general, but apparently it works most of the time, so we shouldn't  
break it if we don't have to.)  
  
We'd already adopted the solution for PL/Perl of inserting the sysroot  
path directly into the -I switches used to find Perl's headers, and we  
can do the same thing for PL/Tcl by changing the -iwithsysroot switch  
that Apple's tclConfig.sh reports.  This restricts the risks to PL/Perl  
and PL/Tcl themselves and directly-dependent extensions, which is a lot  
more pleasing in general than a global -isysroot switch.  
  
Along the way, tighten the test to see if we need to inject the sysroot  
path into $perl_includedir, as I'd speculated about upthread but not  
gotten round to doing.  
  
As before, back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us  

M configure
M configure.in
M src/template/darwin

Avoid rare race condition in privileges.sql regression test.

commit   : 49a1c22889d428558c8e5accb55afa538ef0ca3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Oct 2018 13:56:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Oct 2018 13:56:58 -0400    

Click here for diff

We created a temp table, then switched to a new session, leaving  
the old session to clean up its temp objects in background.  If that  
took long enough, the eventual attempt to drop the user that owns  
the temp table could fail, as exhibited today by sidewinder.  
Fix by dropping the temp table explicitly when we're done with it.  
  
It's been like this for quite some time, so back-patch to all  
supported branches.  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sidewinder&dt=2018-10-16%2014%3A45%3A00  

M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql

Make PostgresNode.pm’s poll_query_until() more chatty about failures.

commit   : 5f920def84a0df35e3a455068ba0ee0df0f45493    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Oct 2018 12:27:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Oct 2018 12:27:14 -0400    

Click here for diff

Reporting only the stderr is unhelpful when the problem is that the  
server output we're getting doesn't match what was expected.  So we  
should report the query output too; and just for good measure, let's  
print the query we used and the output we expected.  
  
Back-patch to 9.5 where poll_query_until was introduced.  
  
Discussion: https://postgr.es/m/17913.1539634756@sss.pgh.pa.us  

M src/test/perl/PostgresNode.pm

Improve stability of recently-added regression test case.

commit   : 6d2c760b059e4f16e2176fcfea6068d58cc3bf30    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Oct 2018 12:01:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Oct 2018 12:01:19 -0400    

Click here for diff

Commit b5febc1d1 added a contrib/btree_gist test case that has been  
observed to fail in the buildfarm as a result of background auto-analyze  
updating stats and changing the selected plan.  Forestall that by  
forcibly analyzing in foreground, instead.  The new plan choice is  
just as good for our purposes, since we really only care that an  
index-only plan does not get selected.  
  
Back-patch to 9.5, like the previous patch.  
  
Discussion: https://postgr.es/m/14643.1539629304@sss.pgh.pa.us  

M contrib/btree_gist/expected/inet.out
M contrib/btree_gist/sql/inet.sql

Avoid statically allocating gmtsub()’s timezone workspace.

commit   : d112682373784b72bb293f6b78b7d8cec0c0aa93    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Oct 2018 11:50:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Oct 2018 11:50:18 -0400    

Click here for diff

localtime.c's "struct state" is a rather large object, ~23KB.  We were  
statically allocating one for gmtsub() to use to represent the GMT  
timezone, even though that function is not at all heavily used and is  
never reached in most backends.  Let's malloc it on-demand, instead.  
  
This does pose the question of how to handle a malloc failure, but  
there's already a well-defined error report convention here, ie  
set errno and return NULL.  
  
We have but one caller of pg_gmtime in HEAD, and two in back branches,  
neither of which were troubling to check for error.  Make them do so.  
The possible errors are sufficiently unlikely (out-of-range timestamp,  
and now malloc failure) that I think elog() is adequate.  
  
Back-patch to all supported branches to keep our copies of the IANA  
timezone code in sync.  This particular change is in a stanza that  
already differs from upstream, so it's a wash for maintenance purposes  
--- but only as long as we keep the branches the same.  
  
Discussion: https://postgr.es/m/20181015200754.7y7zfuzsoux2c4ya@alap3.anarazel.de  

M src/backend/utils/adt/nabstime.c
M src/backend/utils/adt/timestamp.c
M src/timezone/localtime.c