PostgreSQL 9.4.23 commit log

commit   : a01e72fb69cb808364788b5360546f75cf2198df    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2019 17:26:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2019 17:26:08 -0400    

commit   : 5eaeea2cecb98161d41e11aff917c91177a8ad0c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2019 14:45:16 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2019 14:45:16 +0200    

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

commit   : 7f6a69050fadf05c69d61fd070746ab3d1918133    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 16 Jun 2019 15:39:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 16 Jun 2019 15:39:08 -0400    

(11.4 notes are already done.)  

commit   : 6c66865f3c58d0d340aa163c9689ae3a126d4e78    
  
author   : Andrew Gierth <[email protected]>    
date     : Sat, 15 Jun 2019 18:15:23 +0100    
  
committer: Andrew Gierth <[email protected]>    
date     : Sat, 15 Jun 2019 18:15:23 +0100    

tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate  
zone with its own abbreviation. Unfortunately, our code for choosing a  
timezone in initdb has an arbitrary preference for names earlier in  
the alphabet, and so it would choose the spelling "UCT" over "UTC"  
when the system is running on a UTC zone.  
  
Commit 23bd3cec6 was backpatched in order to address this issue, but  
that code helps only when /etc/localtime exists as a symlink, and does  
nothing to help on systems where /etc/localtime is a copy of a zone  
file (as is the standard setup on FreeBSD and probably some other  
platforms too) or when /etc/localtime is simply absent (giving UTC as  
the default).  
  
Accordingly, add a preference for the spelling "UTC", such that if  
multiple zone names have equally good content matches, we prefer that  
name before applying the existing arbitrary rules. Also add a slightly  
lower preference for "Etc/UTC"; lower because that preserves the  
previous behaviour of choosing the shorter name, but letting us still  
choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does  
not (not common, but I've seen it happen).  
  
Backpatch all the way, because the tzdb change that sparked this issue  
is in those branches too.  

commit   : 37011bcb30a9dff84b83a868e5f44c300ddc2f1f    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2019 11:25:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2019 11:25:13 -0400    

On many modern platforms, /etc/localtime is a symlink to a file within the  
IANA database.  Reading the symlink lets us find out the name of the system  
timezone directly, without going through the brute-force search embodied in  
scan_available_timezones().  This shortens the runtime of initdb by some  
tens of ms, which is helpful for the buildfarm, and it also allows us to  
reliably select the same zone name the system was actually configured for,  
rather than possibly choosing one of IANA's many zone aliases.  (For  
example, in a system configured for "Asia/Tokyo", the brute-force search  
would not choose that name but its alias "Japan", on the grounds of the  
latter string being shorter.  More surprisingly, "Navajo" is preferred  
to either "America/Denver" or "US/Mountain", as seen in an old complaint  
from Josh Berkus.)  
  
If /etc/localtime doesn't exist, or isn't a symlink, or we can't make  
sense of its contents, or the contents match a zone we know but that  
zone doesn't match the observed behavior of localtime(), fall back to  
the brute-force search.  
  
Also, tweak initdb so that it prints the zone name it selected.  
  
In passing, replace the last few references to the "Olson" database in  
code comments with "IANA", as that's been our preferred term since  
commit b2cbced9e.  
  
Back-patch of commit 23bd3cec6.  The original intention was to not  
back-patch, since this can result in cosmetic behavioral changes ---  
for example, on my own workstation initdb now chooses "America/New_York",  
where it used to prefer "US/Eastern" which is equivalent and shorter.  
However, our hand has been more or less forced by tzdb update 2019a,  
which made the "UCT" zone fully equivalent to "UTC".  Our old code  
now prefers "UCT" on the grounds of it being alphabetically first,  
and that's making nobody happy.  Choosing the alias indicated by  
/etc/localtime is a more defensible behavior.  (Users who don't like  
the results can always force the decision by setting the TZ environment  
variable before running initdb.)  
  
Patch by me, per a suggestion from Robert Haas; review by Michael Paquier  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 68a0571e2255daa8841d1ee3c0c8c8424659312b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2019 10:53:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2019 10:53:17 -0400    

Also MyReplicationSlot, in branches where it wasn't already.  
  
This was discussed in the thread that resulted in c572599c6, but  
for some reason nobody pulled the trigger.  Now that we have another  
request for the same thing, we should just do it.  
  
Craig Ringer  
  
Discussion: https://postgr.es/m/CAMsr+YFTsq-86MnsNng=mPvjjh5EAbzfMK0ptJPvzyvpFARuRg@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1a3d9f62c1d158585266200b8bbb2d7d757c4eae    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 13 Jun 2019 17:59:17 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 13 Jun 2019 17:59:17 +0900    

Previously, in postgresPlanForeignModify, we planned an UPDATE operation  
on a foreign table so that we transmit only columns that were explicitly  
targets of the UPDATE, so as to avoid unnecessary data transmission, but  
if there were BEFORE ROW UPDATE triggers on the foreign table, those  
triggers might change values for non-target columns, in which case we  
would miss sending changed values for those columns.  Prevent optimizing  
away transmitting all columns if there are BEFORE ROW UPDATE triggers on  
the foreign table.  
  
This is an oversight in commit 7cbe57c34 which added triggers on foreign  
tables, so apply the patch all the way back to 9.4 where that came in.  
  
Author: Shohei Mochizuki  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/[email protected]  

commit   : df88137a398b5a45a95bca14c334b6b708c8018e    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 22:54:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 22:54:46 -0400    

datatype.sgml failed to explain that boolin() accepts any unique  
prefix of the basic input strings.  Indeed it was actively misleading  
because it called out a few minimal prefixes without mentioning that  
there were more valid inputs.  
  
I also felt that it wasn't doing anybody any favors by conflating  
SQL key words, valid Boolean input, and string literals containing  
valid Boolean input.  Rewrite in hopes of reducing the confusion.  
  
Per bug #15836 from Yuming Wang, as diagnosed by David Johnston.  
Back-patch to supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8ace51a6b114208f079407d8e9d7020160c5cc2a    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 19:42:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 19:42:39 -0400    

Given a query in which multiple JOIN nodes used the same alias  
(which'd necessarily be in different sub-SELECTs), ruleutils.c  
would assign the JOIN nodes distinct aliases for clarity ...  
but then it forgot to print the modified aliases when dumping  
the JOIN nodes themselves.  This results in a dump/reload hazard  
for views, because the emitted query is flat-out incorrect:  
Vars will be printed with table names that have no referent.  
  
This has been wrong for a long time, so back-patch to all supported  
branches.  
  
Philip Dubé  
  
Discussion: https://postgr.es/m/CY4PR2101MB080246F2955FF58A6ED1FEAC98140@CY4PR2101MB0802.namprd21.prod.outlook.com  

commit   : 9695ecf360afb5e69fe63b259f3d654c593f8d43    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 12:29:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2019 12:29:25 -0400    

ATExecAlterColumnType failed to consider the possibility that an index  
that needs to be rebuilt might be a child of a constraint that needs to be  
rebuilt.  We missed this so far because usually a constraint index doesn't  
have a direct dependency on its table, just on the constraint object.  
But if there's a WHERE clause, then dependency analysis of the WHERE  
clause results in direct dependencies on the column(s) mentioned in WHERE.  
This led to trying to drop and rebuild both the constraint and its  
underlying index.  
  
In v11/HEAD, we successfully drop both the index and the constraint,  
and then try to rebuild both, and of course the second rebuild hits a  
duplicate-index-name problem.  Before v11, it fails with obscure messages  
about a missing relation OID, due to trying to drop the index twice.  
  
This is essentially the same kind of problem noted in commit  
20bef2c31: the possible dependency linkages are broader than what  
ATExecAlterColumnType was designed for.  It was probably OK when  
written, but it's certainly been broken since the introduction of  
partial exclusion constraints.  Fix by adding an explicit check  
for whether any of the indexes-to-be-rebuilt belong to any of the  
constraints-to-be-rebuilt, and ignoring any that do.  
  
In passing, fix a latent bug introduced by commit 8b08f7d48: in  
get_constraint_index() we must "continue" not "break" when rejecting  
a relation of a wrong relkind.  This is harmless today because we don't  
expect that code path to be taken anyway; but if there ever were any  
relations to be ignored, the existing coding would have an extremely  
undesirable dependency on the order of pg_depend entries.  
  
Also adjust a couple of obsolete comments.  
  
Per bug #15835 from Yaroslav Schekin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 69f32206d7e5d7fd636d8e66dc309eac9b0fceb7    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 10 Jun 2019 23:20:48 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 10 Jun 2019 23:20:48 -0700    

Vignesh found this bug in the check function for  
default_table_access_method's check hook, but that was just copied  
from older GUCs. Investigation by Michael and me then found the bug in  
further places.  
  
When not connected to a database (e.g. in a walsender connection), we  
cannot perform (most) GUC checks that need database access. Even when  
only shared tables are needed, unless they're  
nailed (c.f. RelationCacheInitializePhase2()), they cannot be accessed  
without pg_class etc. being present.  
  
Fix by extending the existing IsTransactionState() checks to also  
check for MyDatabaseOid.  
  
Reported-By: Vignesh C, Michael Paquier, Andres Freund  
Author: Vignesh C, Andres Freund  
Discussion: https://postgr.es/m/CALDaNm1KXK9gbZfY-p_peRFm_XrBh1OwQO1Kk6Gig0c0fVZ2uw%40mail.gmail.com  
Backpatch: 9.4-  

commit   : 79f6efe814e34d61f2c6cfedf0525bac6cf01380    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 1 Jun 2019 15:34:22 -0400    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 1 Jun 2019 15:34:22 -0400    

Support of CHECK OPTION for updatable views has been added in 9.4, but  
the documentation of information_schema never got the call even if the  
information displayed is correct.  
  
Author: Gilles Darold  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : db5d99916e803decb46ca1d3663c3c34d0910ddf    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 31 May 2019 12:34:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 31 May 2019 12:34:55 -0400    

Rename some exposed parameters so that they don't conflict with  
C++ reserved words.  
  
Back-patch to all supported versions.  
  
George Tarasov  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5e6377bcbcdcaf11106ddc1ed583f3548ce47a21    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 23 May 2019 14:59:16 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 23 May 2019 14:59:16 -0700    

On master (after 700538) the old version's installed psql was used -  
even when the old version might not actually be installed / might be  
installed into a temporary directory. As commonly the case when just  
executing make check for pg_upgrade, as $oldbindir is just the current  
version's $bindir.  
  
In the back branches, with --install specified, psql from the new  
version's temporary installation was used, without --install (e.g for  
NO_TEMP_INSTALL, cf 47b3c26642), the new version's installed psql was  
used (which might or might not exist).  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  

commit   : d93ba74c22c2cdbb978f84d51032486c3e05b5dc    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 20 May 2019 09:49:00 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 20 May 2019 09:49:00 +0900    

Discussion: https://postgr.es/m/[email protected]  
Author: Liudmila Mantrova  
Reviewed-by: Jonathan Katz, Tom Lane, Michael Paquier  
Backpatch-through: 9.4  

commit   : bc96e394c23b66728349cbe429a3239a35fe29af    
  
author   : Peter Geoghegan <[email protected]>    
date     : Mon, 13 May 2019 15:38:57 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Mon, 13 May 2019 15:38:57 -0700    

An upcoming HEAD-only patch will standardize the terminology around  
ItemIdData variables/line pointers, ending the practice of referring to  
them as "item pointers".  Make the "Database Page Layout" docs  
consistent with the new policy.  The term "item identifier" is already  
used in the same section, so stick with that.  
  
Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=E4ndQ2--8ew@mail.gmail.com  
Backpatch: All supported branches.  

commit   : b1ca28e57e1209769341451c07d7331c822f25a7    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 12 May 2019 18:53:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 12 May 2019 18:53:13 -0400    

A bounded quantifier with m = n = 1 might be thought a no-op.  But  
according to our documentation (which traces back to Henry Spencer's  
original man page) it still imposes greediness, or non-greediness in the  
case of the non-greedy variant "{1,1}?", on whatever it's attached to.  
  
This turns out not to work though, because parseqatom() optimizes away  
the m = n = 1 case without regard for whether it's supposed to change  
the greediness of the argument RE.  
  
We can fix this by just not applying the optimization when the greediness  
needs to change; the subsequent general cases handle it fine.  
  
The three cases in which we can still apply the optimization are  
(a) no quantifier, or quantifier does not impose a preference;  
(b) atom has no greediness property, implying it cannot match a  
variable amount of text anyway; or  
(c) quantifier's greediness is same as atom's.  
Note that in most cases where one of these applies, we'd have exited  
earlier in the "not a messy case" fast path.  I think it's now only  
possible to get to the optimization when the atom involves capturing  
parentheses or a non-top-level backref.  
  
Back-patch to all supported branches.  I'd ordinarily be hesitant to  
put a subtle behavioral change into back branches, but in this case  
it's very hard to see a reason why somebody would write "{1,1}?" unless  
they're trying to get the documented change-of-greediness behavior.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 08e3fd96f70a711b4d19927d792dde4a04672c15    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 12 May 2019 10:33:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 12 May 2019 10:33:05 -0700    

The function had been interpreting SQL_ASCII messages as UTF8, throwing  
an error when they were invalid UTF8.  The new behavior is consistent  
with pg_do_encoding_conversion().  This affects LOG_DESTINATION_STDERR  
and LOG_DESTINATION_EVENTLOG, which will send untranslated bytes to  
write() and ReportEventA().  On buildfarm member bowerbird, enabling  
log_connections caused an error whenever the role name was not valid  
UTF8.  Back-patch to 9.4 (all supported versions).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 82ed20e15e52c67cea1e3b3b1b8795cdbd249c05    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 11 May 2019 13:01:29 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 11 May 2019 13:01:29 +0900    

When failing to reindex a table, reindexdb would generate an extra error  
message related to a database failure, which is misleading.  
  
Backpatch all the way down, as this has been introduced by 85e9a5a0.  
  
Discussion: https://postgr.es/m/CAOBaU_Yo61RwNO3cW6WVYWwH7EYMPuexhKqufb2nFGOdunbcHw@mail.gmail.com  
Author: Julien Rouhaud  
Reviewed-by: Daniel Gustafsson, Álvaro Herrera, Tom Lane, Michael  
Paquier  
Backpatch-through: 9.4  

commit   : b1cde67a4f94ada93eb314c7751e998377a0fa6a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 May 2019 14:56:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 May 2019 14:56:41 -0400    

There's a very old race condition in our code to see whether a pre-existing  
shared memory segment is still in use by a conflicting postmaster: it's  
possible for the other postmaster to remove the segment in between our  
shmctl() and shmat() calls.  It's a narrow window, and there's no risk  
unless both postmasters are using the same port number, but that's possible  
during parallelized "make check" tests.  (Note that while the TAP tests  
take some pains to choose a randomized port number, pg_regress doesn't.)  
If it does happen, we treated that as an unexpected case and errored out.  
  
To fix, allow EINVAL to be treated as segment-not-present, and the same  
for EIDRM on Linux.  AFAICS, the considerations here are basically  
identical to the checks for acceptable shmctl() failures, so I documented  
and coded it that way.  
  
While at it, adjust PGSharedMemoryAttach's API to remove its undocumented  
dependency on UsedShmemSegAddr in favor of passing the attach address  
explicitly.  This makes it easier to be sure we're using a null shmaddr  
when probing for segment conflicts (thus avoiding questions about what  
EINVAL means).  I don't think there was a bug there, but it required  
fragile assumptions about the state of UsedShmemSegAddr during  
PGSharedMemoryIsInUse.  
  
Commit c09850992 may have made this failure more probable by applying  
the conflicting-segment tests more often.  Hence, back-patch to all  
supported branches, as that was.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : bc250ee7ebd0ff3b5bd1674fbf90a90032bad0fa    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 9 May 2019 01:35:13 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 9 May 2019 01:35:13 +0900    

Previously it's documented that use of replication functions is  
restricted to superusers. This is true for the functions which  
use replication origin, but not for pg_logicl_emit_message() and  
functions which use replication slot. For example, not only  
superusers but also users with REPLICATION privilege is allowed  
to use the functions for replication slot. This commit fixes  
the documentation for the privileges required for those replication  
functions.  
  
Back-patch to 9.4 (all supported versions).  
  
Author: Matsumura Ryo  
Discussion: https://postgr.es/m/03040DFF97E6E54E88D3BFEE5F5480F74ABA6E16@G01JPEXMBYT04  

commit   : 46012d152f8d123ddc9c739aed06d093b8553b66    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 8 May 2019 09:32:34 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 8 May 2019 09:32:34 +0300    

The flat file mechanism was removed in PostgreSQL 9.0.  

commit   : 9a6a1042ab406de4eebcd307a1220c5552567748    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 7 May 2019 14:20:24 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 7 May 2019 14:20:24 +0900    

This code was broken as of 582edc3, and is most likely not used anymore.  
Note that pg_dump supports servers down to 8.0, and psql has code to  
support servers down to 7.4.  
  
Author: Julien Rouhaud  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAOBaU_Y5y=zo3+2gf+2NJC1pvMYPcbRXoQaPXx=U7+C8Qh4CzQ@mail.gmail.com