PostgreSQL 9.5.10 commit log

Stamp 9.5.10.

commit   : 9ce323f612ab19eda1322bb6cf8227b835027511    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2017 17:11:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2017 17:11:00 -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   : 7b4c179b70a59ad2dbd5c928ce8fc84629da0237    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2017 12:02:30 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2017 12:02:30 -0500    

Click here for diff

Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099  

M doc/src/sgml/release-9.2.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

Make json{b}_populate_recordset() use the right tuple descriptor.

commit   : d5fe5fb232a4e57c66779b8b6acdcb458e9b8b9c    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2017 10:29:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2017 10:29:17 -0500    

Click here for diff

json{b}_populate_recordset() used the tuple descriptor created from the  
query-level AS clause without worrying about whether it matched the actual  
input record type.  If it didn't, that would usually result in a crash,  
though disclosure of server memory contents seems possible as well, for a  
skilled attacker capable of issuing crafted SQL commands.  Instead, use  
the query-supplied descriptor only when there is no input tuple to look at,  
and otherwise get a tuple descriptor based on the input tuple's own type  
marking.  The core code will detect any type mismatch in the latter case.  
  
Michael Paquier and Tom Lane, per a report from David Rowley.  
Back-patch to 9.3 where this functionality was introduced.  
  
Security: CVE-2017-15098  

M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/json.out
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql

start-scripts: switch to $PGUSER before opening $PGLOG.

commit   : ed546dd06195c27d92ae46f2bb1a74261bcb49e6    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 6 Nov 2017 07:11:10 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 6 Nov 2017 07:11:10 -0800    

Click here for diff

By default, $PGUSER has permission to unlink $PGLOG.  If $PGUSER  
replaces $PGLOG with a symbolic link, the server will corrupt the  
link-targeted file by appending log messages.  Since these scripts open  
$PGLOG as root, the attack works regardless of target file ownership.  
  
"make install" does not install these scripts anywhere.  Users having  
manually installed them in the past should repeat that process to  
acquire this fix.  Most script users have $PGLOG writable to root only,  
located in $PGDATA.  Just before updating one of these scripts, such  
users should rename $PGLOG to $PGLOG.old.  The script will then recreate  
$PGLOG with proper ownership.  
  
Reviewed by Peter Eisentraut.  Reported by Antoine Scemama.  
  
Security: CVE-2017-12172  

M contrib/start-scripts/freebsd
M contrib/start-scripts/linux
M contrib/start-scripts/osx/PostgreSQL

Always require SELECT permission for ON CONFLICT DO UPDATE.

commit   : 045a18888f38bd46f5b50e145470095f461cc41c    
  
author   : Dean Rasheed <[email protected]>    
date     : Mon, 6 Nov 2017 09:15:11 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Mon, 6 Nov 2017 09:15:11 +0000    

Click here for diff

The update path of an INSERT ... ON CONFLICT DO UPDATE requires SELECT  
permission on the columns of the arbiter index, but it failed to check  
for that in the case of an arbiter specified by constraint name.  
  
In addition, for a table with row level security enabled, it failed to  
check updated rows against the table's SELECT policies when the update  
path was taken (regardless of how the arbiter index was specified).  
  
Backpatch to 9.5 where ON CONFLICT DO UPDATE and RLS were introduced.  
  
Security: CVE-2017-15099  

M src/backend/catalog/pg_constraint.c
M src/backend/parser/parse_clause.c
M src/backend/rewrite/rowsecurity.c
M src/include/catalog/pg_constraint.h
M src/test/regress/expected/privileges.out
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/privileges.sql
M src/test/regress/sql/rowsecurity.sql

Add a temp-install prerequisite to "check"-like targets not having one.

commit   : 014c5cd8767161995278bc1f4e2fcfb1b703dad1    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 5 Nov 2017 18:51:08 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 5 Nov 2017 18:51:08 -0800    

Click here for diff

Makefile.global assigns this prerequisite to every target named "check",  
but similar targets must mention it explicitly.  Affected targets  
failed, tested $PATH binaries, or tested a stale temporary installation.  
The src/test/modules examples worked properly when called as "make -C  
src/test/modules/$FOO check", but "make -j" allowed the test to start  
before the temporary installation was in place.  Back-patch to 9.5,  
where commit dcae5faccab64776376d354decda0017c648bb53 introduced the  
shared temp-install.  

M src/interfaces/ecpg/test/Makefile
M src/test/locale/Makefile
M src/test/modules/brin/Makefile
M src/test/regress/GNUmakefile

Translation updates

commit   : 4dc03c8609b5a0ca725a3ee4d6077f23f81461b8    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 5 Nov 2017 17:02:54 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 5 Nov 2017 17:02:54 -0500    

Click here for diff

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 64f85a7ee5a763d2eb6e938e1aeb90ed17dbb69f  

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/bin/pg_dump/po/it.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/it.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/pg_rewind/po/de.po
M src/bin/pg_rewind/po/fr.po
M src/bin/pg_rewind/po/it.po
M src/bin/pg_rewind/po/ru.po
M src/bin/psql/po/it.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/it.po
M src/interfaces/libpq/po/ru.po

Release notes for 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24.

commit   : eb0080401100ccff730983a0d08d0787ff6f5b32    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 5 Nov 2017 13:47:56 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 5 Nov 2017 13:47:56 -0500    

Click here for diff

In the v10 branch, also back-patch the effects of 1ff01b390 and c29c57890  
on these files, to reduce future maintenance issues.  (I'd do it further  
back, except that the 9.X branches differ anyway due to xlog-to-wal  
link tag renaming.)  

M doc/src/sgml/release-9.2.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

Ignore CatalogSnapshot when checking COPY FREEZE prerequisites.

commit   : 7932891ab9ccfa5003a8dce9af0bea60427469b3    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 5 Nov 2017 09:25:52 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 5 Nov 2017 09:25:52 -0800    

Click here for diff

This restores the ability, essentially lost in commit  
ffaa44cb559db332baeee7d25dedd74a61974203, to use COPY FREEZE under  
REPEATABLE READ isolation.  Back-patch to 9.4, like that commit.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/CA+TgmoahWDm-7fperBxzU9uZ99LPMUmEpSXLTw9TmrOgzwnORw@mail.gmail.com  

M src/backend/commands/copy.c
M src/backend/utils/time/snapmgr.c

Fix BRIN summarization concurrent with extension

commit   : cf0612aa2c8fdc54bb98a13ef839f43cef5eadc5    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 3 Nov 2017 17:23:13 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 3 Nov 2017 17:23:13 +0100    

Click here for diff

If a process is extending a table concurrently with some BRIN  
summarization process, it is possible for the latter to miss pages added  
by the former because the number of pages is computed ahead of time.  
  
Fix by determining a fresh relation size after inserting the placeholder  
tuple: any process that further extends the table concurrently will  
update the placeholder tuple, while previous pages will be processed by  
the heap scan.  
  
Reported-by: Tomas Vondra  
Reviewed-by: Tom Lane  
Author: Álvaro Herrera  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-to: 9.5  

M src/backend/access/brin/brin.c

Improve error message for incorrect number inputs in libecpg.

commit   : 90d61bd1d16bb51d9bbc07e2e345e49bed7310fe    
  
author   : Michael Meskes <[email protected]>    
date     : Fri, 3 Nov 2017 11:14:30 +0100    
  
committer: Michael Meskes <[email protected]>    
date     : Fri, 3 Nov 2017 11:14:30 +0100    

Click here for diff

M src/interfaces/ecpg/ecpglib/data.c

Fix float parsing in ecpg INFORMIX mode.

commit   : b6d95939ed6fc8bde97eb8c9af00838dde82cc41    
  
author   : Michael Meskes <[email protected]>    
date     : Thu, 2 Nov 2017 20:46:34 +0100    
  
committer: Michael Meskes <[email protected]>    
date     : Thu, 2 Nov 2017 20:46:34 +0100    

Click here for diff

M src/interfaces/ecpg/ecpglib/data.c

Fix corner-case errors in brin_doupdate().

commit   : 43276abc6f7e497bfca2277b9e04585fcd6c25c5    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 2 Nov 2017 12:54:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 2 Nov 2017 12:54:23 -0400    

Click here for diff

In some cases the BRIN code releases lock on an index page, and later  
re-acquires lock and tries to check that the tuple it was working on is  
still there.  That check was a couple bricks shy of a load.  It didn't  
consider that the page might have turned into a "revmap" page.  (The  
samepage code path doesn't call brin_getinsertbuffer(), so it isn't  
protected by the checks for revmap status there.)  It also didn't check  
whether the tuple offset was now off the end of the linepointer array.  
Since commit 24992c6db the latter case is pretty common, but at least  
in principle it could have occurred before that.  The net result is  
that concurrent updates of a BRIN index could fail with errors like  
"invalid index offnum" or "inconsistent range map".  
  
Per report from Tomas Vondra.  Back-patch to 9.5, since this code is  
substantially the same in all versions containing BRIN.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/access/brin/brin_pageops.c

Revert bogus fixes of HOT-freezing bug

commit   : b3888b60d3f04a27ceaf68cb60e2c2d100c6b753    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 2 Nov 2017 15:51:05 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 2 Nov 2017 15:51:05 +0100    

Click here for diff

It turns out we misdiagnosed what the real problem was.  Revert the  
previous changes, because they may have worse consequences going  
forward.  A better fix is forthcoming.  
  
The simplistic test case is kept, though disabled.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/access/heap/heapam.c
M src/backend/access/heap/pruneheap.c
M src/backend/commands/vacuumlazy.c
M src/backend/executor/execMain.c
M src/include/access/heapam.h
M src/test/isolation/isolation_schedule

Doc: update URL for check_postgres.

commit   : 7ae39519bf0eca229f7ae98a391b161c43fe88a9    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 1 Nov 2017 22:07:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 1 Nov 2017 22:07:14 -0400    

Click here for diff

Reported by Dan Vianello.  
  
Discussion: https://postgr.es/m/e6e12f18f70e46848c058084d42fb651@KSTLMEXGP001.CORP.CHARTERCOM.com  

M doc/src/sgml/maintenance.sgml

pg_basebackup: Fix comparison handling of tablespace mappings on Windows

commit   : 3064f0e25fc728385c873e776b0bf08a3f3ea09c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 1 Nov 2017 10:20:05 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 1 Nov 2017 10:20:05 -0400    

Click here for diff

A candidate path needs to be canonicalized before being checked against  
the mappings, because the mappings are also canonicalized.  This is  
especially relevant on Windows  
  
Reported-by: nb <[email protected]>  
Author: Michael Paquier <[email protected]>  
Reviewed-by: Ashutosh Sharma <[email protected]>  

M src/bin/pg_basebackup/pg_basebackup.c

Make sure ecpglib does accepts digits behind decimal point even for integers in Informix mode.

commit   : d2e6bd13a0729a12d04811a9e192f94898556041    
  
author   : Michael Meskes <[email protected]>    
date     : Wed, 1 Nov 2017 13:32:18 +0100    
  
committer: Michael Meskes <[email protected]>    
date     : Wed, 1 Nov 2017 13:32:18 +0100    

Click here for diff

Spotted and fixed by 高增琦 <[email protected]>  

M src/interfaces/ecpg/ecpglib/data.c

Dept of second thoughts: keep aliasp_item in sync with tlistitem.

commit   : 1f81c2cd524e0c65a621d280255be559ab630e4a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Oct 2017 18:16:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 27 Oct 2017 18:16:25 -0400    

Click here for diff

Commit d5b760ecb wasn't quite right, on second thought: if the  
caller didn't ask for column names then it would happily emit  
more Vars than if the caller did ask for column names.  This  
is surely not a good idea.  Advance the aliasp_item whether or  
not we're preparing a colnames list.  

M src/backend/parser/parse_relation.c

Fix crash when columns have been added to the end of a view.

commit   : acd3287e437eea6df51d7b0aaa2909efc7c9219e    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Oct 2017 17:10:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 27 Oct 2017 17:10:21 -0400    

Click here for diff

expandRTE() supposed that an RTE_SUBQUERY subquery must have exactly  
as many non-junk tlist items as the RTE has column aliases for it.  
This was true at the time the code was written, and is still true so  
far as parse analysis is concerned --- but when the function is used  
during planning, the subquery might have appeared through insertion  
of a view that now has more columns than it did when the outer query  
was parsed.  This results in a core dump if, for instance, we have  
to expand a whole-row Var that references the subquery.  
  
To avoid crashing, we can either stop expanding the RTE when we run  
out of aliases, or invent new aliases for the added columns.  While  
the latter might be more useful, the former is consistent with what  
expandRTE() does for composite-returning functions in the RTE_FUNCTION  
case, so it seems like we'd better do it that way.  
  
Per bug #14876 from Samuel Horwitz.  This has been busted since commit  
ff1ea2173 allowed views to acquire more columns, so back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/parser/parse_relation.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql

Rethink the dependencies recorded for FieldSelect/FieldStore nodes.

commit   : 37fb01cb04b4b1c6e7d0532cdb64cb730be119b2    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Oct 2017 12:18:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 27 Oct 2017 12:18:57 -0400    

Click here for diff

On closer investigation, commits f3ea3e3e8 et al were a few bricks  
shy of a load.  What we need is not so much to lock down the result  
type of a FieldSelect, as to lock down the existence of the column  
it's trying to extract.  Otherwise, we can break it by dropping that  
column.  The dependency on the result type is then held indirectly  
through the column, and doesn't need to be recorded explicitly.  
  
Out of paranoia, I left in the code to record a dependency on the  
result type, but it's used only if we can't identify the pg_class OID  
for the column.  That shouldn't ever happen right now, AFAICS, but  
it seems possible that in future the input node could be marked as  
being of type RECORD rather than some specific composite type.  
  
Likewise for FieldStore.  
  
Like the previous patch, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/catalog/dependency.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql

Doc: mention that you can't PREPARE TRANSACTION after NOTIFY.

commit   : 1c715f1713a01b33ea2768bd8789a6e9ebfe8b39    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Oct 2017 10:46:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 27 Oct 2017 10:46:06 -0400    

Click here for diff

The NOTIFY page said this already, but the PREPARE TRANSACTION page  
missed it.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ref/prepare_transaction.sgml

Improve gendef.pl diagnostic on failure to open sym file

commit   : 351d9b7d4e2539de6dd6b948a5ba128f07032b0b    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 26 Oct 2017 10:10:37 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 26 Oct 2017 10:10:37 -0400    

Click here for diff

There have been numerous buildfarm failures but the diagnostic is  
currently silent about the reason for failure to open the file. Let's  
see if we can get to the bottom of it.  
  
Backpatch to all live branches.  

M src/tools/msvc/gendef.pl

Fixed handling of escape character in libecpg.

commit   : 9b01a21fc10986ca0e7ca349f0f1a2cc55b386f7    
  
author   : Michael Meskes <[email protected]>    
date     : Thu, 26 Oct 2017 10:16:04 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Thu, 26 Oct 2017 10:16:04 +0200    

Click here for diff

Patch by Tsunakawa Takayuki <[email protected]>  

M src/interfaces/ecpg/ecpglib/execute.c

Fix libpq to not require user's home directory to exist.

commit   : ee02c1c897eeabbb16cb0155e993f98d18c90069    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 25 Oct 2017 19:32:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 25 Oct 2017 19:32:24 -0400    

Click here for diff

Some people like to run libpq-using applications in environments where  
there's no home directory.  We've broken that scenario before (cf commits  
5b4067798 and bd58d9d88), and commit ba005f193 broke it again, by making  
it a hard error if we fail to get the home directory name while looking  
for ~/.pgpass.  The previous precedent is that if we can't get the home  
directory name, we should just silently act as though the file we hoped  
to find there doesn't exist.  Rearrange the new code to honor that.  
  
Looking around, the service-file code added by commit 41a4e4595 had the  
same disease.  Apparently, that escaped notice because it only runs when  
a service name has been specified, which I guess the people who use this  
scenario don't do.  Nonetheless, it's wrong too, so fix that case as well.  
  
Add a comment about this policy to pqGetHomeDirectory, in the probably  
vain hope of forestalling the same error in future.  And upgrade the  
rather miserable commenting in parseServiceInfo, too.  
  
In passing, also back off parseServiceInfo's assumption that only ENOENT  
is an ignorable error from stat() when checking a service file.  We would  
need to ignore at least ENOTDIR as well (cf 5b4067798), and seeing that  
the far-better-tested code for ~/.pgpass treats all stat() failures alike,  
I think this code ought to as well.  
  
Per bug #14872 from Dan Watson.  Back-patch the .pgpass change to v10  
where ba005f193 came in.  The service-file bugs are far older, so  
back-patch the other changes to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

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

Process variadic arguments consistently in json functions

commit   : 3cc5f0550538e72de5245fa464a18d979278839e    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 25 Oct 2017 07:34:00 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 25 Oct 2017 07:34:00 -0400    

Click here for diff

json_build_object and json_build_array and the jsonb equivalents did not  
correctly process explicit VARIADIC arguments. They are modified to use  
the new extract_variadic_args() utility function which abstracts away  
the details of the call method.  
  
Michael Paquier, reviewed by Tom Lane and Dmitry Dolgov.  
  
Backpatch to 9.5 for the jsonb fixes and 9.4 for the json fixes, as  
that's where they originated.  

M src/backend/utils/adt/json.c
M src/backend/utils/adt/jsonb.c
M src/test/regress/expected/json.out
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql

Add a utility function to extract variadic function arguments

commit   : 5c8dcd322c0ef38c257c80813de9afb0107ccc98    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 25 Oct 2017 07:13:11 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 25 Oct 2017 07:13:11 -0400    

Click here for diff

This is epecially useful in the case or "VARIADIC ANY" functions. The  
caller can get the artguments and types regardless of whether or not and  
explicit VARIADIC array argument has been used. The function also  
provides an option to convert arguments on type "unknown" to to "text".  
  
Michael Paquier and me, reviewed by Tom Lane.  
  
Backpatch to 9.4 in order to support the following json bug fix.  

M src/backend/utils/fmgr/funcapi.c
M src/include/funcapi.h

Update time zone data files to tzdata release 2017c.

commit   : 1e57d85cdaee2faee2a2863a2b3bd1c675d4734b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 Oct 2017 18:15:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 23 Oct 2017 18:15:36 -0400    

Click here for diff

DST law changes in Fiji, Namibia, Northern Cyprus, Sudan, Tonga,  
and Turks & Caicos Islands.  Historical corrections for Alaska, Apia,  
Burma, Calcutta, Detroit, Ireland, Namibia, and Pago Pago.  

M src/timezone/data/africa
M src/timezone/data/antarctica
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/backward
M src/timezone/data/backzone
M src/timezone/data/europe
M src/timezone/data/northamerica
M src/timezone/data/southamerica

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

commit   : 4b433a8b0122a07d6f537075779c02cdabbe7b02    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 Oct 2017 17:54:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 23 Oct 2017 17:54:09 -0400    

Click here for diff

This is a trivial update containing only cosmetic changes.  The point  
is just to get back to being synced with an official release of tzcode,  
rather than some ad-hoc point in their commit history, which is where  
commit 47f849a3c left it.  

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

Fix some oversights in expression dependency recording.

commit   : aa0518301fd86b60df70ff50f4035a34cb6815ed    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 Oct 2017 13:57:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 23 Oct 2017 13:57:45 -0400    

Click here for diff

find_expr_references() neglected to record a dependency on the result type  
of a FieldSelect node, allowing a DROP TYPE to break a view or rule that  
contains such an expression.  I think we'd omitted this case intentionally,  
reasoning that there would always be a related dependency ensuring that the  
DROP would cascade to the view.  But at least with nested field selection  
expressions, that's not true, as shown in bug #14867 from Mansur Galiev.  
Add the dependency, and for good measure a dependency on the node's exposed  
collation.  
  
Likewise add a dependency on the result type of a FieldStore.  I think here  
the reasoning was that it'd only appear within an assignment to a field,  
and the dependency on the field's column would be enough ... but having  
seen this example, I think that's wrong for nested-composites cases.  
  
Looking at nearby code, I notice we're not recording a dependency on the  
exposed collation of CoerceViaIO, which seems inconsistent with our choices  
for related node types.  Maybe that's OK but I'm feeling suspicious of this  
code today, so let's add that; it certainly can't hurt.  
  
This patch does not do anything to protect already-existing views, only  
views created after it's installed.  But seeing that the issue has been  
there a very long time and nobody noticed till now, that's probably good  
enough.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/catalog/dependency.c

Fix typcache's failure to treat ranges as container types.

commit   : 63fbc51e396d60429345c4a0856b6a7197198344    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Oct 2017 17:12:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Oct 2017 17:12:27 -0400    

Click here for diff

Like the similar logic for arrays and records, it's necessary to examine  
the range's subtype to decide whether the range type can support hashing.  
We can omit checking the subtype for btree-defined operations, though,  
since range subtypes are required to have those operations.  (Possibly  
that simplification for btree cases led us to overlook that it does  
not apply for hash cases.)  
  
This is only an issue if the subtype lacks hash support, which is not  
true of any built-in range type, but it's easy to demonstrate a problem  
with a range type over, eg, money: you can get a "could not identify  
a hash function" failure when the planner is misled into thinking that  
hash join or aggregation would work.  
  
This was born broken, so back-patch to all supported branches.  

M src/backend/utils/cache/typcache.c
M src/test/regress/expected/rangetypes.out
M src/test/regress/sql/rangetypes.sql

Fix misparsing of non-newline-terminated pg_hba.conf files.

commit   : 9e20276e13c2fd04396d5178de7210a2179cd347    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 17 Oct 2017 12:15:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 17 Oct 2017 12:15:08 -0400    

Click here for diff

This back-patches the v10-cycle commit 1e5a5d03d into 9.3 - 9.6.  
I had noticed at the time that that was fixing a bug, namely that  
next_token() might advance *lineptr past the line-terminating '\0',  
but given the lack of field complaints I too easily convinced myself  
that the problem was only latent.  It's not, because tokenize_file()  
decides whether there's more on the line using "strlen(lineptr)".  
  
The bug is indeed latent on a newline-terminated line, because then  
the newline-stripping bit in tokenize_file() means we'll have two  
or more consecutive '\0's in the buffer, masking the fact that we  
accidentally advanced over the first one.  But the last line in  
the file might not be null-terminated, allowing the loop to see  
and process garbage, as reported by Mark Jones in bug #14859.  
  
The bug doesn't exist in <= 9.2; there next_token() is reading directly  
from a file, and termination of the outer loop relies on an feof() test  
not a buffer pointer check.  Probably commit 7f49a67f9 can be blamed  
for this bug, but I didn't track it down exactly.  
  
Commit 1e5a5d03d does a bit more than the minimum needed to fix the  
bug, but I felt the rest of it was good cleanup, so applying it all.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/libpq/hba.c

Doc: fix missing explanation of default object privileges.

commit   : 8d6f4e7ec56c73f5aa225a037e63eee71a4a3108    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 11 Oct 2017 16:56:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 11 Oct 2017 16:56:23 -0400    

Click here for diff

The GRANT reference page, which lists the default privileges for new  
objects, failed to mention that USAGE is granted by default for data  
types and domains.  As a lesser sin, it also did not specify anything  
about the initial privileges for sequences, FDWs, foreign servers,  
or large objects.  Fix that, and add a comment to acldefault() in the  
probably vain hope of getting people to maintain this list in future.  
  
Noted by Laurenz Albe, though I editorialized on the wording a bit.  
Back-patch to all supported branches, since they all have this behavior.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ref/grant.sgml
M src/backend/utils/adt/acl.c

Fix low-probability loss of NOTIFY messages due to XID wraparound.

commit   : 69bc245d92961d5db83aabefb9a8b5646732b797    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 11 Oct 2017 14:28:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 11 Oct 2017 14:28:33 -0400    

Click here for diff

Up to now async.c has used TransactionIdIsInProgress() to detect whether  
a notify message's source transaction is still running.  However, that  
function has a quick-exit path that reports that XIDs before RecentXmin  
are no longer running.  If a listening backend is doing nothing but  
listening, and not running any queries, there is nothing that will advance  
its value of RecentXmin.  Once 2 billion transactions elapse, the  
RecentXmin check causes active transactions to be reported as not running.  
If they aren't committed yet according to CLOG, async.c decides they  
aborted and discards their messages.  The timing for that is a bit tight  
but it can happen when multiple backends are sending notifies concurrently.  
The net symptom therefore is that a sufficiently-long-surviving  
listen-only backend starts to miss some fraction of NOTIFY traffic,  
but only under heavy load.  
  
The only function that updates RecentXmin is GetSnapshotData().  
A brute-force fix would therefore be to take a snapshot before  
processing incoming notify messages.  But that would add cycles,  
as well as contention for the ProcArrayLock.  We can be smarter:  
having taken the snapshot, let's use that to check for running  
XIDs, and not call TransactionIdIsInProgress() at all.  In this  
way we reduce the number of ProcArrayLock acquisitions from one  
per message to one per notify interrupt; that's the same under  
light load but should be a benefit under heavy load.  Light testing  
says that this change is a wash performance-wise for normal loads.  
  
I looked around for other callers of TransactionIdIsInProgress()  
that might be at similar risk, and didn't find any; all of them  
are inside transactions that presumably have already taken a  
snapshot.  
  
Problem report and diagnosis by Marko Tiikkaja, patch by me.  
Back-patch to all supported branches, since it's been like this  
since 9.0.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/async.c
M src/backend/utils/time/tqual.c
M src/include/utils/tqual.h

Fix crash when logical decoding is invoked from a PL function.

commit   : 13d2ed921035f2d88adf87d796373e920bdd56ee    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Oct 2017 19:18:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Oct 2017 19:18:59 -0400    

Click here for diff

The logical decoding functions do BeginInternalSubTransaction and  
RollbackAndReleaseCurrentSubTransaction to clean up after themselves.  
It turns out that AtEOSubXact_SPI has an unrecognized assumption that  
we always need to cancel the active SPI operation in the SPI context  
that surrounds the subtransaction (if there is one).  That's true  
when the RollbackAndReleaseCurrentSubTransaction call is coming from  
the SPI-using function itself, but not when it's happening inside  
some unrelated function invoked by a SPI query.  In practice the  
affected callers are the various PLs.  
  
To fix, record the current subtransaction ID when we begin a SPI  
operation, and clean up only if that ID is the subtransaction being  
canceled.  
  
Also, remove AtEOSubXact_SPI's assertion that it must have cleaned  
up the surrounding SPI context's active tuptable.  That's proven  
wrong by the same test case.  
  
Also clarify (or, if you prefer, reinterpret) the calling conventions  
for _SPI_begin_call and _SPI_end_call.  The memory context cleanup  
in the latter means that these have always had the flavor of a matched  
resource-management pair, but they weren't documented that way before.  
  
Per report from Ben Chobot.  
  
Back-patch to 9.4 where logical decoding came in.  In principle,  
the SPI changes should go all the way back, since the problem dates  
back to commit 7ec1c5a86.  But given the lack of field complaints  
it seems few people are using internal subtransactions in this way.  
So I don't feel a need to take any risks in 9.2/9.3.  
  
Discussion: https://postgr.es/m/[email protected]  

M contrib/test_decoding/expected/decoding_into_rel.out
M contrib/test_decoding/sql/decoding_into_rel.sql
M src/backend/executor/spi.c
M src/include/executor/spi_priv.h

Fix access-off-end-of-array in clog.c.

commit   : c7c93dd55af5d15e22a7343f15fdf917f61304fb    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Oct 2017 12:20:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Oct 2017 12:20:13 -0400    

Click here for diff

Sloppy loop coding in set_status_by_pages() resulted in fetching one array  
element more than it should from the subxids[] array.  The odds of this  
resulting in SIGSEGV are pretty small, but we've certainly seen that happen  
with similar mistakes elsewhere.  While at it, we can get rid of an extra  
TransactionIdToPage() calculation per loop.  
  
Per report from David Binderman.  Back-patch to all supported branches,  
since this code is quite old.  
  
Discussion: https://postgr.es/m/HE1PR0802MB2331CBA919CBFFF0C465EB429C710@HE1PR0802MB2331.eurprd08.prod.outlook.com  

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

Fix traversal of half-frozen update chains

commit   : fc0df3bdafd68c652999c59b5f56d07ef2fd9c25    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 6 Oct 2017 17:14:42 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 6 Oct 2017 17:14:42 +0200    

Click here for diff

When some tuple versions in an update chain are frozen due to them being  
older than freeze_min_age, the xmax/xmin trail can become broken.  This  
breaks HOT (and probably other things).  A subsequent VACUUM can break  
things in more serious ways, such as leaving orphan heap-only tuples  
whose root HOT redirect items were removed.  This can be seen because  
index creation (or REINDEX) complain like  
  ERROR:  XX000: failed to find parent tuple for heap-only tuple at (0,7) in table "t"  
  
Because of relfrozenxid contraints, we cannot avoid the freezing of the  
early tuples, so we must cope with the results: whenever we see an Xmin  
of FrozenTransactionId, consider it a match for whatever the previous  
Xmax value was.  
  
This problem seems to have appeared in 9.3 with multixact changes,  
though strictly speaking it seems unrelated.  
  
Since 9.4 we have commit 37484ad2a "Change the way we mark tuples as  
frozen", so the fix is simple: just compare the raw Xmin (still stored  
in the tuple header, since freezing merely set an infomask bit) to the  
Xmax.  But in 9.3 we rewrite the Xmin value to FrozenTransactionId, so  
the original value is lost and we have nothing to compare the Xmax with.  
To cope with that case we need to compare the Xmin with FrozenXid,  
assume it's a match, and hope for the best.  Sadly, since you can  
pg_upgrade a 9.3 instance containing half-frozen pages to newer  
releases, we need to keep the old check in newer versions too, which  
seems a bit brittle; I hope we can somehow get rid of that.  
  
I didn't optimize the new function for performance.  The new coding is  
probably a bit slower than before, since there is a function call rather  
than a straight comparison, but I'd rather have it work correctly than  
be fast but wrong.  
  
This is a followup after 20b655224249 fixed a few related problems.  
Apparently, in 9.6 and up there are more ways to get into trouble, but  
in 9.3 - 9.5 I cannot reproduce a problem anymore with this patch, so  
there must be a separate bug.  
  
Reported-by: Peter Geoghegan  
Diagnosed-by: Peter Geoghegan, Michael Paquier, Daniel Wood,  
	Yi Wen Wong, Álvaro  
Discussion: https://postgr.es/m/CAH2-Wznm4rCrhFAiwKPWTpEw2bXDtgROZK7jWWGucXeH3D1fmA@mail.gmail.com  

M src/backend/access/heap/heapam.c
M src/backend/access/heap/pruneheap.c
M src/backend/executor/execMain.c
M src/include/access/heapam.h

Fix more user-visible elog() calls.

commit   : 32022e3f55eab593bcd829341216810730911d51    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 5 Oct 2017 07:58:02 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 5 Oct 2017 07:58:02 -0400    

Click here for diff

Michael Paquier discovered that this could be triggered via SQL;  
give a nicer message instead.  
  
Patch by Michael Paquier, reviewed by Masahiko Sawada.  
  
Discussion: http://postgr.es/m/CAB7nPqQtPg+LKKtzdKN26judHcvPZ0s1gNigzOT4j8CYuuuBYg@mail.gmail.com  

M contrib/test_decoding/expected/replorigin.out
M contrib/test_decoding/sql/replorigin.sql
M src/backend/replication/logical/origin.c

Fix coding rules violations in walreceiver.c

commit   : 182abe31387c31bef5cefa700d8ff193ff595713    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 3 Oct 2017 14:58:25 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 3 Oct 2017 14:58:25 +0200    

Click here for diff

1. Since commit b1a9bad9e744 we had pstrdup() inside a  
spinlock-protected critical section; reported by Andreas Seltenreich.  
Turn those into strlcpy() to stack-allocated variables instead.  
Backpatch to 9.6.  
  
2. Since commit 9ed551e0a4fd we had a pfree() uselessly inside a  
spinlock-protected critical section.  Tom Lane noticed in code review.  
Move down.  Backpatch to 9.6.  
  
3. Since commit 64233902d22b we had GetCurrentTimestamp() (a kernel  
call) inside a spinlock-protected critical section.  Tom Lane noticed in  
code review.  Move it up.  Backpatch to 9.2.  
  
4. Since commit 1bb2558046cc we did elog(PANIC) while holding spinlock.  
Tom Lane noticed in code review.  Release spinlock before dying.  
Backpatch to 9.2.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/replication/walreceiver.c

Use a longer connection timeout in pg_isready test.

commit   : 10cb052404b431fc04958286849d97209fd097f7    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 1 Oct 2017 12:43:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 1 Oct 2017 12:43:47 -0400    

Click here for diff

Buildfarm members skink and sungazer have both recently failed this  
test, with symptoms indicating that the default 3-second timeout  
isn't quite enough for those very slow systems.  There's no reason  
to be miserly with this timeout, so boost it to 60 seconds.  
  
Back-patch to all versions containing this test.  That may be overkill,  
because the failure has only been observed in the v10 branch, but  
I don't feel like having to revisit this later.  

M src/bin/scripts/t/080_pg_isready.pl

Fix freezing of a dead HOT-updated tuple

commit   : fb6de78a291b1871fd9a426b4d0f51230bac3259    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 28 Sep 2017 16:44:01 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 28 Sep 2017 16:44:01 +0200    

Click here for diff

Vacuum calls page-level HOT prune to remove dead HOT tuples before doing  
liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples.  But  
concurrent transaction commit/abort may turn DEAD some of the HOT tuples  
that survived the prune, before HeapTupleSatisfiesVacuum tests them.  
This happens to activate the code that decides to freeze the tuple ...  
which resuscitates it, duplicating data.  
  
(This is especially bad if there's any unique constraints, because those  
are now internally violated due to the duplicate entries, though you  
won't know until you try to REINDEX or dump/restore the table.)  
  
One possible fix would be to simply skip doing anything to the tuple,  
and hope that the next HOT prune would remove it.  But there is a  
problem: if the tuple is older than freeze horizon, this would leave an  
unfrozen XID behind, and if no HOT prune happens to clean it up before  
the containing pg_clog segment is truncated away, it'd later cause an  
error when the XID is looked up.  
  
Fix the problem by having the tuple freezing routines cope with the  
situation: don't freeze the tuple (and keep it dead).  In the cases that  
the XID is older than the freeze age, set the HEAP_XMAX_COMMITTED flag  
so that there is no need to look up the XID in pg_clog later on.  
  
An isolation test is included, authored by Michael Paquier, loosely  
based on Daniel Wood's original reproducer.  It only tests one  
particular scenario, though, not all the possible ways for this problem  
to surface; it be good to have a more reliable way to test this more  
fully, but it'd require more work.  
In message https://postgr.es/m/[email protected]  
I outlined another test case (more closely matching Dan Wood's) that  
exposed a few more ways for the problem to occur.  
  
Backpatch all the way back to 9.3, where this problem was introduced by  
multixact juggling.  In branches 9.3 and 9.4, this includes a backpatch  
of commit e5ff9fefcd50 (of 9.5 era), since the original is not  
correctable without matching the coding pattern in 9.5 up.  
  
Reported-by: Daniel Wood  
Diagnosed-by: Daniel Wood  
Reviewed-by: Yi Wen Wong, Michaël Paquier  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/access/heap/heapam.c
M src/backend/commands/vacuumlazy.c
A src/test/isolation/expected/freeze-the-dead.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/freeze-the-dead.spec

Fix behavior when converting a float infinity to numeric.

commit   : ad56dbd6c0b87e95fb1cf45025bb7dd8152a9f59    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 27 Sep 2017 17:05:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 27 Sep 2017 17:05:53 -0400    

Click here for diff

float8_numeric() and float4_numeric() failed to consider the possibility  
that the input is an IEEE infinity.  The results depended on the  
platform-specific behavior of sprintf(): on most platforms you'd get  
something like  
  
ERROR:  invalid input syntax for type numeric: "inf"  
  
but at least on Windows it's possible for the conversion to succeed and  
deliver a finite value (typically 1), due to a nonstandard output format  
from sprintf and lack of syntax error checking in these functions.  
  
Since our numeric type lacks the concept of infinity, a suitable conversion  
is impossible; the best thing to do is throw an explicit error before  
letting sprintf do its thing.  
  
While at it, let's use snprintf not sprintf.  Overrunning the buffer  
should be impossible if sprintf does what it's supposed to, but this  
is cheap insurance against a stack smash if it doesn't.  
  
Problem reported by Taiki Kondo.  Patch by me based on fix suggestion  
from KaiGai Kohei.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql

Improve the CREATE POLICY documentation.

commit   : 6a21eb31b6deb0f76e8304fb9f12df272ed59f0c    
  
author   : Dean Rasheed <[email protected]>    
date     : Wed, 27 Sep 2017 17:07:08 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Wed, 27 Sep 2017 17:07:08 +0100    

Click here for diff

Provide a correct description of how multiple policies are combined,  
clarify when SELECT permissions are required, mention SELECT FOR  
UPDATE/SHARE, and do some other more minor tidying up.  
  
Reviewed by Stephen Frost  
  
Discussion: https://postgr.es/m/CAEZATCVrxyYbOFU8XbGHicz%2BmXPYzw%3DhfNL2XTphDt-53TomQQ%40mail.gmail.com  
  
Back-patch to 9.5.  

M doc/src/sgml/ref/create_policy.sgml

Don't recommend "DROP SCHEMA information_schema CASCADE".

commit   : 2e7f6b6b2a214f8f5fa8ec448807c3a1a2c8b897    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 26 Sep 2017 22:39:44 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 26 Sep 2017 22:39:44 -0700    

Click here for diff

It drops objects outside information_schema that depend on objects  
inside information_schema.  For example, it will drop a user-defined  
view if the view query refers to information_schema.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/release-9.2.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

Improve wording of error message added in commit 714805010.

commit   : bd797eaa9a056d95e9a1b657755d3abc2d93a6c8    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 15:25:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 15:25:56 -0400    

Click here for diff

Per suggestions from Peter Eisentraut and David Johnston.  
Back-patch, like the previous commit.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/analyze.c
M src/test/regress/expected/vacuum.out

Fix failure-to-read-man-page in commit 899bd785c.

commit   : 06852f21544c061cb4d4b53bbe16a647a12dd311    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 13:42:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 13:42:53 -0400    

Click here for diff

posix_fallocate() is not quite a drop-in replacement for fallocate(),  
because it is defined to return the error code as its function result,  
not in "errno".  I (tgl) missed this because RHEL6's version seems  
to set errno as well.  That is not the case on more modern Linuxen,  
though, as per buildfarm results.  
  
Aside from fixing the return-convention confusion, remove the test  
for ENOSYS; we expect that glibc will mask that for posix_fallocate,  
though it does not for fallocate.  Keep the test for EINTR, because  
POSIX specifies that as a possible result, and buildfarm results  
suggest that it can happen in practice.  
  
Back-patch to 9.4, like the previous commit.  
  
Thomas Munro  
  
Discussion: https://postgr.es/m/[email protected]  

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

Avoid SIGBUS on Linux when a DSM memory request overruns tmpfs.

commit   : 05297416f362b50985b3cd3473778fbb0842295d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 25 Sep 2017 16:09:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 25 Sep 2017 16:09:20 -0400    

Click here for diff

On Linux, shared memory segments created with shm_open() are backed by  
swap files created in tmpfs.  If the swap file needs to be extended,  
but there's no tmpfs space left, you get a very unfriendly SIGBUS trap.  
To avoid this, force allocation of the full request size when we create  
the segment.  This adds a few cycles, but none that we wouldn't expend  
later anyway, assuming the request isn't hugely bigger than the actual  
need.  
  
Make this code #ifdef __linux__, because (a) there's not currently a  
reason to think the same problem exists on other platforms, and (b)  
applying posix_fallocate() to an FD created by shm_open() isn't very  
portable anyway.  
  
Back-patch to 9.4 where the DSM code came in.  
  
Thomas Munro, per a bug report from Amul Sul  
  
Discussion: https://postgr.es/m/[email protected]  

M configure
M configure.in
M src/backend/storage/ipc/dsm_impl.c
M src/include/pg_config.h.in
M src/include/pg_config.h.win32

Fix saving and restoring umask

commit   : acae13faabc505146817f4834a8c9e9b43788312    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 22 Sep 2017 16:50:59 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 22 Sep 2017 16:50:59 -0400    

Click here for diff

In two cases, we set a different umask for some piece of code and  
restore it afterwards.  But if the contained code errors out, the umask  
is not restored.  So add TRY/CATCH blocks to fix that.  

M src/backend/commands/copy.c
M src/backend/libpq/be-fsstubs.c

Sync our copy of the timezone library with IANA tzcode master.

commit   : 89f02e17a6ac81bbc78ea92f2ead06d8816ee297    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 22 Sep 2017 00:04:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 22 Sep 2017 00:04:21 -0400    

Click here for diff

This patch absorbs a few unreleased fixes in the IANA code.  
It corresponds to commit 2d8b944c1cec0808ac4f7a9ee1a463c28f9cd00a  
in https://github.com/eggert/tz.  Non-cosmetic changes include:  
  
TZDEFRULESTRING is updated to match current US DST practice,  
rather than what it was over ten years ago.  This only matters  
for interpretation of POSIX-style zone names (e.g., "EST5EDT"),  
and only if the timezone database doesn't include either an exact  
match for the zone name or a "posixrules" entry.  The latter  
should not be true in any current Postgres installation, but  
this could possibly matter when using --with-system-tzdata.  
  
Get rid of a nonportable use of "++var" on a bool var.  
This is part of a larger fix that eliminates some vestigial  
support for consecutive leap seconds, and adds checks to  
the "zic" compiler that the data files do not specify that.  
  
Remove a couple of ancient compatibility hacks.  The IANA  
crew think these are obsolete, and I tend to agree.  But  
perhaps our buildfarm will think different.  
  
Back-patch to all supported branches, in line with our policy  
that all branches should be using current IANA code.  Before v10,  
this includes application of current pgindent rules, to avoid  
whitespace problems in future back-patches.  
  
Discussion: https://postgr.es/m/[email protected]  

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

Give a better error for duplicate entries in VACUUM/ANALYZE column list.

commit   : 122289a66b92799885917953907d5b3f3f9e6ac2    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Sep 2017 18:13:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Sep 2017 18:13:11 -0400    

Click here for diff

Previously, the code didn't think about this case and would just try to  
analyze such a column twice.  That would fail at the point of inserting  
the second version of the pg_statistic row, with obscure error messsages  
like "duplicate key value violates unique constraint" or "tuple already  
updated by self", depending on context and PG version.  We could allow  
the case by ignoring duplicate column specifications, but it seems better  
to reject it explicitly.  
  
The bogus error messages seem like arguably a bug, so back-patch to  
all supported versions.  
  
Nathan Bossart, per a report from Michael Paquier, and whacked  
around a bit by me.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/analyze.c
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql

Fix erroneous documentation about noise word GROUP.

commit   : 6f5e7a87406f2a52c270b34f257f1c41d631b575    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 20 Sep 2017 11:10:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 20 Sep 2017 11:10:42 -0400    

Click here for diff

GRANT, REVOKE, and some allied commands allow the noise word GROUP  
before a role name (cf. grantee production in gram.y).  This option  
does not exist elsewhere, but it had nonetheless snuck into the  
documentation for ALTER ROLE, ALTER USER, and CREATE SCHEMA.  
  
Seems to be a copy-and-pasteo in commit 31eae6028, which did expand the  
syntax choices here, but not in that way.  Back-patch to 9.5 where that  
came in.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ref/alter_role.sgml
M doc/src/sgml/ref/alter_user.sgml
M doc/src/sgml/ref/create_schema.sgml

docs: re-add instructions on setting wal_level for rsync use

commit   : 8aa520045e1427f6f2ee0881e6d551546787da55    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 20 Sep 2017 09:36:19 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 20 Sep 2017 09:36:19 -0400    

Click here for diff

This step was erroneously removed four days ago by me.  
  
Reported-by: Magnus via IM  
  
Backpatch-through: 9.5  

M doc/src/sgml/ref/pgupgrade.sgml

Mention need for --no-inc-recursive in rsync command

commit   : df1fb03640caab20d6415ca914ff0e32c48df934    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 20 Sep 2017 14:09:05 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 20 Sep 2017 14:09:05 +0200    

Click here for diff

Since rsync 3.0.0 (released in 2008), the default way to enumerate  
changes was changed in a way that makes it less likely that the hardlink  
sync mode works. Since the whole point of the documented procedure is  
for the hardlinks to work, change our docs to suggest using the  
backwards compatibility switch.  

M doc/src/sgml/ref/pgupgrade.sgml

Fixed ECPG to correctly handle out-of-scope cursor declarations with pointers or array variables.

commit   : 3a5aa7de311788d9f5ae2fb235801738ae888b50    
  
author   : Michael Meskes <[email protected]>    
date     : Mon, 11 Sep 2017 21:10:36 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Mon, 11 Sep 2017 21:10:36 +0200    

Click here for diff

M src/interfaces/ecpg/preproc/ecpg.header

Allow rel_is_distinct_for() to look through RelabelType below OpExpr.

commit   : eeff6839633d97c03a43889ed7c83df81d513f08    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 15:28:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 15:28:51 -0400    

Click here for diff

This lets it do the right thing for, eg, varchar columns.  
Back-patch to 9.5 where this logic appeared.  
  
David Rowley, per report from Kim Rose Carlsen  
  
Discussion: https://postgr.es/m/VI1PR05MB17091F9A9876528055D6A827C76D0@VI1PR05MB1709.eurprd05.prod.outlook.com  

M src/backend/optimizer/plan/analyzejoins.c

Fix possible dangling pointer dereference in trigger.c.

commit   : 825fac5d33a606a1410111c5be195e5af3a0c433    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 14:50:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 14:50:01 -0400    

Click here for diff

AfterTriggerEndQuery correctly notes that the query_stack could get  
repalloc'd during a trigger firing, but it nonetheless passes the address  
of a query_stack entry to afterTriggerInvokeEvents, so that if such a  
repalloc occurs, afterTriggerInvokeEvents is already working with an  
obsolete dangling pointer while it scans the rest of the events.  Oops.  
The only code at risk is its "delete_ok" cleanup code, so we can  
prevent unsafe behavior by passing delete_ok = false instead of true.  
  
However, that could have a significant performance penalty, because the  
point of passing delete_ok = true is to not have to re-scan possibly  
a large number of dead trigger events on the next time through the loop.  
There's more than one way to skin that cat, though.  What we can do is  
delete all the "chunks" in the event list except the last one, since  
we know all events in them must be dead.  Deleting the chunks is work  
we'd have had to do later in AfterTriggerEndQuery anyway, and it ends  
up saving rescanning of just about the same events we'd have gotten  
rid of with delete_ok = true.  
  
In v10 and HEAD, we also have to be careful to mop up any per-table  
after_trig_events pointers that would become dangling.  This is slightly  
annoying, but I don't think that normal use-cases will traverse this code  
path often enough for it to be a performance problem.  
  
It's pretty hard to hit this in practice because of the unlikelihood  
of the query_stack getting resized at just the wrong time.  Nonetheless,  
it's definitely a live bug of ancient standing, so back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/trigger.c

docs: clarify pg_upgrade docs regarding standbys and rsync

commit   : 2efe122c5a479c03493995adadc8c80bec8015da    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 16 Sep 2017 11:58:00 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 16 Sep 2017 11:58:00 -0400    

Click here for diff

Document that rsync is an _optional_ way to upgrade standbys, suggest  
rsync option --dry-run, and mention a way of upgrading one standby from  
another using rsync.  Also clarify some instructions by specifying if  
they operate on the old or new clusters.  
  
Reported-by: Stephen Frost, Magnus Hagander  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

M doc/src/sgml/ref/pgupgrade.sgml

commit   : e1795efcbecdcb53d3910cd46a067a1e66ab0938    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 13 Sep 2017 09:22:18 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 13 Sep 2017 09:22:18 -0400    

Click here for diff

Backpatch-through: 9.5  

M doc/src/sgml/ref/pgupgrade.sgml

docs: improve pg_upgrade standby instructions

commit   : 213409c6a3ed9d8976985b76f51822c32a710691    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 13 Sep 2017 09:11:28 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 13 Sep 2017 09:11:28 -0400    

Click here for diff

This makes it clear that pg_upgrade standby upgrade instructions should  
only be used in link mode, adds examples, and explains how rsync works  
with links.  
  
Reported-by: Andreas Joseph Krogh  
  
Discussion: https://postgr.es/m/VisenaEmail.6c.c0e592c5af4ef0a2.15e785dcb61@tc7-visena  
  
Backpatch-through: 9.5  

M doc/src/sgml/ref/pgupgrade.sgml

docs: improve pg_upgrade rsync instructions

commit   : 5d2e18d6ec3bdc042a37b1a9e577679e4b829bea    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 12 Sep 2017 13:17:52 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 12 Sep 2017 13:17:52 -0400    

Click here for diff

This explains how rsync accomplishes updating standby servers and  
clarifies the instructions.  
  
Reported-by: Andreas Joseph Krogh  
  
Discussion: https://postgr.es/m/VisenaEmail.10.2b4049e43870bd16.15d898d696f@tc7-visena  
  
Backpatch-through: 9.5  

M doc/src/sgml/ref/pgupgrade.sgml

Fix translatable string

commit   : 8d5ec8ee38090989d1f626d9dc477960206bd9dc    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 4 Sep 2017 11:08:52 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 4 Sep 2017 11:08:52 +0200    

Click here for diff

Discussion: https://postgr.es/m/[email protected]  

M src/bin/pg_rewind/libpq_fetch.c

Fix macro-redefinition warning on MSVC.

commit   : 1d30553aa2356e434062cd7bc3744579e97f328b    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 3 Sep 2017 11:01:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 3 Sep 2017 11:01:08 -0400    

Click here for diff

In commit 9d6b160d7, I tweaked pg_config.h.win32 to use  
"#define HAVE_LONG_LONG_INT_64 1" rather than defining it as empty,  
for consistency with what happens in an autoconf'd build.  
But Solution.pm injects another definition of that macro into  
ecpg_config.h, leading to justifiable (though harmless) compiler whining.  
Make that one consistent too.  Back-patch, like the previous patch.  
  
Discussion: https://postgr.es/m/CAEepm=1dWsXROuSbRg8PbKLh0S=8Ou-V8sr05DxmJOF5chBxqQ@mail.gmail.com  

M src/tools/msvc/Solution.pm

doc: Fix typos and other minor issues

commit   : 2efd54b45a892661c50a87c1cf78e964fa2b7e00    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 1 Sep 2017 22:59:27 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 1 Sep 2017 22:59:27 -0400    

Click here for diff

Author: Alexander Lakhin <[email protected]>  

M doc/src/sgml/event-trigger.sgml
M doc/src/sgml/logicaldecoding.sgml
M doc/src/sgml/perform.sgml

Make [U]INT64CONST safe for use in #if conditions.

commit   : 1305186de4257cb342bc3b8b0b899cfc00e79c7d    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 1 Sep 2017 15:14:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 1 Sep 2017 15:14:18 -0400    

Click here for diff

Instead of using a cast to force the constant to be the right width,  
assume we can plaster on an L, UL, LL, or ULL suffix as appropriate.  
The old approach to this is very hoary, dating from before we were  
willing to require compilers to have working int64 types.  
  
This fix makes the PG_INT64_MIN, PG_INT64_MAX, and PG_UINT64_MAX  
constants safe to use in preprocessor conditions, where a cast  
doesn't work.  Other symbolic constants that might be defined using  
[U]INT64CONST are likewise safer than before.  
  
Also fix the SIZE_MAX macro to be similarly safe, if we are forced  
to provide a definition for that.  The test added in commit 2e70d6b5e  
happens to do what we want even with the hack "(size_t) -1" definition,  
but we could easily get burnt on other tests in future.  
  
Back-patch to all supported branches, like the previous commits.  
  
Discussion: https://postgr.es/m/[email protected]  

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

Ensure SIZE_MAX can be used throughout our code.

commit   : bf387028554f45bf0af926525d6db12e7ee4281e    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 1 Sep 2017 13:52:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 1 Sep 2017 13:52:54 -0400    

Click here for diff

Pre-C99 platforms may lack <stdint.h> and thereby SIZE_MAX.  We have  
a couple of places using the hack "(size_t) -1" as a fallback, but  
it wasn't universally available; which means the code added in commit  
2e70d6b5e fails to compile everywhere.  Move that hack to c.h so that  
we can rely on having SIZE_MAX everywhere.  
  
Per discussion, it'd be a good idea to make the macro's value safe  
for use in #if-tests, but that will take a bit more work.  This is  
just a quick expedient to get the buildfarm green again.  
  
Back-patch to all supported branches, like the previous commit.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/include/c.h
M src/include/utils/memutils.h
M src/timezone/private.h

Doc: document libpq's restriction to INT_MAX rows in a PGresult.

commit   : c7e990bb0f4dfa2fc33e3755a5996da890e5c9cc    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 15:38:05 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 15:38:05 -0400    

Click here for diff

As long as PQntuples, PQgetvalue, etc, use "int" for row numbers, we're  
pretty much stuck with this limitation.  The documentation formerly stated  
that the result of PQntuples "might overflow on 32-bit operating systems",  
which is just nonsense: that's not where the overflow would happen, and  
if you did reach an overflow it would not be on a 32-bit machine, because  
you'd have OOM'd long since.  
  
Discussion: https://postgr.es/m/CA+FnnTxyLWyjY1goewmJNxC==HQCCF4fKkoCTa9qR36oRAHDPw@mail.gmail.com  

M doc/src/sgml/libpq.sgml

Teach libpq to detect integer overflow in the row count of a PGresult.

commit   : dfd1042c6ae5973d4485d08bf6f122d0b00f50cb    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 15:18:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 15:18:01 -0400    

Click here for diff

Adding more than 1 billion rows to a PGresult would overflow its ntups and  
tupArrSize fields, leading to client crashes.  It'd be desirable to use  
wider fields on 64-bit machines, but because all of libpq's external APIs  
use plain "int" for row counters, that's going to be hard to accomplish  
without an ABI break.  Given the lack of complaints so far, and the general  
pain that would be involved in using such huge PGresults, let's settle for  
just preventing the overflow and reporting a useful error message if it  
does happen.  Also, for a couple more lines of code we can increase the  
threshold of trouble from INT_MAX/2 to INT_MAX rows.  
  
To do that, refactor pqAddTuple() to allow returning an error message that  
replaces the default assumption that it failed because of out-of-memory.  
  
Along the way, fix PQsetvalue() so that it reports all failures via  
pqInternalNotice().  It already did so in the case of bad field number,  
but neglected to report anything for other error causes.  
  
Because of the potential for crashes, this seems like a back-patchable  
bug fix, despite the lack of field reports.  
  
Michael Paquier, per a complaint from Igor Korot.  
  
Discussion: https://postgr.es/m/CA+FnnTxyLWyjY1goewmJNxC==HQCCF4fKkoCTa9qR36oRAHDPw@mail.gmail.com  

M src/interfaces/libpq/fe-exec.c

Improve docs about numeric formatting patterns (to_char/to_number).

commit   : 5c81c881f7caceffb9dd3174a72a724db04d073f    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 09:34:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 09:34:21 -0400    

Click here for diff

The explanation about "0" versus "9" format characters was confusing  
and arguably wrong; the discussion of sign handling wasn't very good  
either.  Notably, while it's accurate to say that "FM" strips leading  
zeroes in date/time values, what it really does with numeric values  
is to strip *trailing* zeroes, and then only if you wrote "9" rather  
than "0".  Per gripes from Erwin Brandstetter.  
  
Discussion: https://postgr.es/m/CAGHENJ7jgRbTn6nf48xNZ=FHgL2WQ4X8mYsUAU57f-vq8PubEw@mail.gmail.com  
Discussion: https://postgr.es/m/CAGHENJ45ymd=GOCu1vwV9u7GmCR80_5tW0fP9C_gJKbruGMHvQ@mail.gmail.com  

M doc/src/sgml/func.sgml