PostgreSQL 9.4.15 commit log

Stamp 9.4.15.

commit   : de7dabfd35e8f657af9a54cb0ff3171e1cf8e957    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2017 17:13:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2017 17:13:17 -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   : e7bae63e02dee20fdcbad2664d4722c80febf8a1    
  
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

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

commit   : 70846ee0597b4aabc11ffe252eb972de6f77a021    
  
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   : 29d06705194396d46004a48bf56e741c79269790    
  
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

Translation updates

commit   : d4fcc0ceaa9029267c8605d79049e24e6fc0551b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 5 Nov 2017 17:04:00 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 5 Nov 2017 17:04:00 -0500    

Click here for diff

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

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/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   : 168b41b65b83275977b1eae4cb1a42cadf9e8e80    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 5 Nov 2017 13:47:57 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 5 Nov 2017 13:47:57 -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

Ignore CatalogSnapshot when checking COPY FREEZE prerequisites.

commit   : 2a2e2e85e0f67213816126d654615413930dd8b3    
  
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

Improve error message for incorrect number inputs in libecpg.

commit   : 946f165182a2e643c18fa21b563dc3ccc0c9ada7    
  
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   : ad24e7bc28d45b180726d6ff144e58d67e73aaa4    
  
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

Revert bogus fixes of HOT-freezing bug

commit   : ef0339ee5dcf933949f3751d98771e03b8c19aa2    
  
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   : f570ec5181e1aeff4fc8ea229e50bd666d35062f    
  
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

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

commit   : 18647e21db0dd797c6ea75d7106d831f92a982e9    
  
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   : d01d97c25cf425acc097520bc1c6af57dff51c44    
  
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   : 66104119e1fbcfd8c8d9fe0c016e0349ff977ba4    
  
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   : 376ac922df7815bc88709090e3b70b7752e9a327    
  
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   : 55429227ce20bf7285b027370a04dab530beb762    
  
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   : 562c50a4bf551f972384ceab135ea53969299641    
  
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   : c6a3968889046e1367ec6f6054f776433237631f    
  
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   : 9f7afb25b911f1591864d63e26eeaa2226f245fb    
  
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   : 9cb28e98b818288b70f165d08ddd295b799466c2    
  
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/test/regress/expected/json.out
M src/test/regress/sql/json.sql

Add a utility function to extract variadic function arguments

commit   : 7f89fc418223d7bfe5cafd5b781a84332954f82a    
  
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   : ba67fac85487e957ea98be8d06508bd2ebbd52f2    
  
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   : 876e076ebe074b63360d172f755ac5dea3d989b1    
  
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   : d8a3be52f44d81637527adf1e86480c5c6fe31a5    
  
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   : d1ced611463d9b0fd0a3cb125e3d75d73ab16554    
  
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   : 38f17e8eeb48ad6aad7174ac7b1af9dcdbaf4a2e    
  
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   : 264b00fca7f0fb2bbe0635e6bfea3a73de71133d    
  
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   : 0e84f70752cfda9bb25ace3fd15de176e968b0ee    
  
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   : bfb69b1e5d97dae636370b713993465cfacddd34    
  
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   : c209b5034ecb7cfa2bd09c960bdf0a22afaa0986    
  
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   : 8b6d85f2dc1ed01fc3272703abb2c267859468eb    
  
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 coding rules violations in walreceiver.c

commit   : 6b2daef96d4343d2fb06c6a64e94b63a13d0cce5    
  
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   : 45ec8da100a1adcbc792025db59d3009d78da02d    
  
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   : 232c7cbcbbc67640a18fb36d292929772ba797ea    
  
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   : c38575edce0d75d4464af7b4153ba0cbf654fd9d    
  
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

Don't recommend "DROP SCHEMA information_schema CASCADE".

commit   : c8178929c55e5424b6c47014579bfbf68886f444    
  
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

Improve wording of error message added in commit 714805010.

commit   : 14f94ac697cf6b70d939a1263d79d32a3362760b    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 15:25:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 15:25:57 -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   : e5c058e2eed865114886823d010cece747914f8d    
  
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   : 3a07a6f3e8d204e2141f09c20de4caecd998fa3f    
  
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   : 9bf04994697dd094032d08682a25cbba7aba523f    
  
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   : dbd6099fbc7783aa167eebc15a0688a613e16635    
  
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   : b572b435ca67a2c032187d376baa271f9049b7cf    
  
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

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

commit   : e5b8b771e7a98e3620679cd9873ad2507ab87fb5    
  
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

Fix possible dangling pointer dereference in trigger.c.

commit   : bc0974703daba859fe171ea6a424eaada7604ee5    
  
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

Fix macro-redefinition warning on MSVC.

commit   : 143fcf90b15884d8e20868996651b17ad333f8ee    
  
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   : b187702f8a74530f861c397153c22a3f4100300b    
  
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/logicaldecoding.sgml
M doc/src/sgml/perform.sgml

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

commit   : 53863ebeba5fa103022c5fe47cd35314b952be59    
  
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   : 9a98557662a9a2c58483f7415f79551194c19edb    
  
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   : 2338ad26374ef27c7601bb5a1517a6a0c82ef94e    
  
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   : 1c53722ffd0088679cb548da2bce569b5c2f9732    
  
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   : e19e12be48337e85d9f5d8a38c1a10e2d425ce1f    
  
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