Stamp 9.2.19.
commit : b3453562b349a104b92ff02289cf41ff09a8a875
author : Tom Lane <[email protected]>
date : Mon, 24 Oct 2016 16:17:41 -0400
committer: Tom Lane <[email protected]>
date : Mon, 24 Oct 2016 16:17:41 -0400
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Translation updates
commit : 89dabaf4a256d2c07c143af125db575cc59ae114
author : Peter Eisentraut <[email protected]>
date : Mon, 24 Oct 2016 12:00:00 -0400
committer: Peter Eisentraut <[email protected]>
date : Mon, 24 Oct 2016 12:00:00 -0400
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 4536e21f450b2265a262f9f9acf912ae5416a1ee
M src/backend/po/de.po
M src/backend/po/ru.po
M src/bin/initdb/po/ru.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/pt_BR.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/cs.po
M src/interfaces/ecpg/preproc/po/de.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/ecpg/preproc/po/it.po
M src/interfaces/ecpg/preproc/po/pl.po
M src/interfaces/ecpg/preproc/po/pt_BR.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/ecpg/preproc/po/zh_CN.po
M src/interfaces/libpq/po/ru.po
M src/interfaces/libpq/po/zh_CN.po
M src/interfaces/libpq/po/zh_TW.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/ru.po
Release notes for 9.6.1, 9.5.5, 9.4.10, 9.3.15, 9.2.19, 9.1.24.
commit : d30c38f418bcc8379f4b9efd8e7fed0859571a74
author : Tom Lane <[email protected]>
date : Sun, 23 Oct 2016 22:13:29 -0400
committer: Tom Lane <[email protected]>
date : Sun, 23 Oct 2016 22:13:29 -0400
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
Avoid testing tuple visibility without buffer lock in RI_FKey_check().
commit : 9bc01e7a4cd4d5ac0c9447a5885f3a5b1bd46dd0
author : Tom Lane <[email protected]>
date : Sun, 23 Oct 2016 15:01:24 -0400
committer: Tom Lane <[email protected]>
date : Sun, 23 Oct 2016 15:01:24 -0400
Despite the argumentation I wrote in commit 7a2fe85b0, it's unsafe to do
this, because in corner cases it's possible for HeapTupleSatisfiesSelf
to try to set hint bits on the target tuple; and at least since 8.2 we
have required the buffer content lock to be held while setting hint bits.
The added regression test exercises one such corner case. Unpatched, it
causes an assertion failure in assert-enabled builds, or otherwise would
cause a hint bit change in a buffer we don't hold lock on, which given
the right race condition could result in checksum failures or other data
consistency problems. The odds of a problem in the field are probably
pretty small, but nonetheless back-patch to all supported branches.
Report: <[email protected]>
M src/backend/utils/adt/ri_triggers.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Doc: wording tweak for PERL, PYTHON, TCLSH configuration variables.
commit : afed471bf382fee399eaf7be0a417900a2cf0417
author : Tom Lane <[email protected]>
date : Fri, 21 Oct 2016 11:01:35 -0400
committer: Tom Lane <[email protected]>
date : Fri, 21 Oct 2016 11:01:35 -0400
Replace "Full path to ..." with "Full path name of ...". At least one
user has misinterpreted the existing wording as meaning "Directory
containing ...".
M doc/src/sgml/installation.sgml
Fix EXPLAIN so that it doesn't emit invalid XML in corner cases.
commit : f17c26dbd6ce08c723b34a08d8dbac5deab9d8c6
author : Tom Lane <[email protected]>
date : Thu, 20 Oct 2016 17:17:50 -0400
committer: Tom Lane <[email protected]>
date : Thu, 20 Oct 2016 17:17:50 -0400
With track_io_timing = on, EXPLAIN (ANALYZE, BUFFERS) will emit fields
named like "I/O Read Time". The slash makes that invalid as an XML
element name, so that adding FORMAT XML would produce invalid XML.
We already have code in there to translate spaces to dashes, so let's
generalize that to convert anything that isn't a valid XML name character,
viz letters, digits, hyphens, underscores, and periods. We could just
reject slashes, which would run a bit faster. But the fact that this went
unnoticed for so long doesn't give me a warm feeling that we'd notice the
next creative violation, so let's make it a permanent fix.
Reported by Markus Winand, though this isn't his initial patch proposal.
Back-patch to 9.2 where track_io_timing was added. The problem is only
latent in 9.1, so I don't feel a need to fix it there.
Discussion: <[email protected]>
M src/backend/commands/explain.c
Sync our copy of the timezone library with IANA release tzcode2016h.
commit : b2aee4cb684e06b00e85d5e7c0de114b5df6010a
author : Tom Lane <[email protected]>
date : Thu, 20 Oct 2016 15:40:07 -0400
committer: Tom Lane <[email protected]>
date : Thu, 20 Oct 2016 15:40:07 -0400
This absorbs a fix for a symlink-manipulation bug in zic that was
introduced in 2016g. It probably isn't interesting for our use-case,
but I'm not quite sure, so let's update while we're at it.
M src/timezone/zic.c
Update time zone data files to tzdata release 2016h.
commit : 3c5fae786d13e3309715b2a57f2a25e247f884ce
author : Tom Lane <[email protected]>
date : Thu, 20 Oct 2016 15:20:11 -0400
committer: Tom Lane <[email protected]>
date : Thu, 20 Oct 2016 15:20:11 -0400
(Didn't I just do this? Oh well.)
DST law changes in Palestine. Historical corrections for Turkey.
Switch to numeric abbreviations for Asia/Colombo.
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/europe
M src/timezone/data/northamerica
M src/timezone/known_abbrevs.txt
Another portability fix for tzcode2016g update.
commit : 0d386bdb6c65c251f9a595247455527c441ebfd3
author : Tom Lane <[email protected]>
date : Wed, 19 Oct 2016 23:32:08 -0400
committer: Tom Lane <[email protected]>
date : Wed, 19 Oct 2016 23:32:08 -0400
clang points out that SIZE_MAX wouldn't fit into an int, which means
this comparison is pretty useless. Per report from Thomas Munro.
M src/timezone/zic.c
Windows portability fix.
commit : d5911df8a707993e819457a99c76e50a2fe49591
author : Tom Lane <[email protected]>
date : Wed, 19 Oct 2016 19:28:11 -0400
committer: Tom Lane <[email protected]>
date : Wed, 19 Oct 2016 19:28:11 -0400
Per buildfarm.
M src/timezone/zic.c
Sync our copy of the timezone library with IANA release tzcode2016g.
commit : 66adeefdad85f1ee062ecf894b800641f284d334
author : Tom Lane <[email protected]>
date : Wed, 19 Oct 2016 18:55:52 -0400
committer: Tom Lane <[email protected]>
date : Wed, 19 Oct 2016 18:55:52 -0400
This is mostly to absorb some corner-case fixes in zic for year-2037
timestamps. The other changes that have been made are unlikely to affect
our usage, but nonetheless we may as well take 'em.
M src/timezone/localtime.c
M src/timezone/private.h
M src/timezone/strftime.c
M src/timezone/zic.c
Suppress "Factory" zone in pg_timezone_names view for tzdata >= 2016g.
commit : 579beef2e571d38502e6b6b402dc47f8484ec7ae
author : Tom Lane <[email protected]>
date : Wed, 19 Oct 2016 18:11:49 -0400
committer: Tom Lane <[email protected]>
date : Wed, 19 Oct 2016 18:11:49 -0400
IANA got rid of the really silly "abbreviation" and replaced it with one
that's only moderately silly. But it's still pointless, so keep on not
showing it.
M src/backend/utils/adt/datetime.c
Update time zone data files to tzdata release 2016g.
commit : a03339aef2b8b5e8379a9550b8ce2add5b436e9f
author : Tom Lane <[email protected]>
date : Wed, 19 Oct 2016 17:56:38 -0400
committer: Tom Lane <[email protected]>
date : Wed, 19 Oct 2016 17:56:38 -0400
DST law changes in Turkey. Historical corrections for America/Los_Angeles,
Europe/Kirov, Europe/Moscow, Europe/Samara, and Europe/Ulyanovsk.
Rename Asia/Rangoon to Asia/Yangon, with a backward compatibility link.
The IANA crew continue their campaign to replace invented time zone
abbrevations with numeric GMT offsets. This update changes numerous zones
in Antarctica and the former Soviet Union, for instance Antarctica/Casey
now reports "+08" not "AWST" in the pg_timezone_names view. I kept these
abbreviations in the tznames/ data files, however, so that we will still
accept them for input. (We may want to start trimming those files someday,
but today is not that day.)
An exception is that since IANA no longer claims that "AMT" is in use
in Armenia for GMT+4, I replaced it in the Default file with GMT-4,
corresponding to Amazon Time which is in use in South America. It may be
that that meaning is also invented and IANA will drop it in a future
update; but for now, it seems silly to give pride of place to a meaning
not traceable to IANA over one that is.
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/etcetera
M src/timezone/data/europe
M src/timezone/data/factory
M src/timezone/data/northamerica
M src/timezone/data/southamerica
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/Antarctica.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Europe.txt
M src/timezone/tznames/Indian.txt
Fix cidin() to handle values above 2^31 platform-independently.
commit : eb338c1cd5347b428725c8d7a79769640c2e10d3
author : Tom Lane <[email protected]>
date : Tue, 18 Oct 2016 12:24:46 -0400
committer: Tom Lane <[email protected]>
date : Tue, 18 Oct 2016 12:24:46 -0400
CommandId is declared as uint32, and values up to 4G are indeed legal.
cidout() handles them properly by treating the value as unsigned int.
But cidin() was just using atoi(), which has platform-dependent behavior
for values outside the range of signed int, as reported by Bart Lengkeek
in bug #14379. Use strtoul() instead, as xidin() does.
In passing, make some purely cosmetic changes to make xidin/xidout
look more like cidin/cidout; the former didn't have a monopoly on
best practice IMO.
Neither xidin nor cidin make any attempt to throw error for invalid input.
I didn't change that here, and am not sure it's worth worrying about
since neither is really a user-facing type. The point is just to ensure
that indubitably-valid inputs work as expected.
It's been like this for a long time, so back-patch to all supported
branches.
Report: <[email protected]>
M src/backend/utils/adt/xid.c
Fix assorted integer-overflow hazards in varbit.c.
commit : a567b7c11b311e4ea3a2668591b48ae52021961d
author : Tom Lane <[email protected]>
date : Fri, 14 Oct 2016 16:28:34 -0400
committer: Tom Lane <[email protected]>
date : Fri, 14 Oct 2016 16:28:34 -0400
bitshiftright() and bitshiftleft() would recursively call each other
infinitely if the user passed INT_MIN for the shift amount, due to integer
overflow in negating the shift amount. To fix, clamp to -VARBITMAXLEN.
That doesn't change the results since any shift distance larger than the
input bit string's length produces an all-zeroes result.
Also fix some places that seemed inadequately paranoid about input typmods
exceeding VARBITMAXLEN. While a typmod accepted by anybit_typmodin() will
certainly be much less than that, at least some of these spots are
reachable with user-chosen integer values.
Andreas Seltenreich and Tom Lane
Discussion: <[email protected]>
M src/backend/utils/adt/varbit.c
Fix another bug in merging of inherited CHECK constraints.
commit : 6f2db29ecb3c2bdb57dd11b5fec85af637e6602f
author : Tom Lane <[email protected]>
date : Thu, 13 Oct 2016 17:05:15 -0400
committer: Tom Lane <[email protected]>
date : Thu, 13 Oct 2016 17:05:15 -0400
It's not good for an inherited child constraint to be marked connoinherit;
that would result in the constraint not propagating to grandchild tables,
if any are created later. The code mostly prevented this from happening
but there was one case that was missed.
This is somewhat related to commit e55a946a8, which also tightened checks
on constraint merging. Hence, back-patch to 9.2 like that one. This isn't
so much because there's a concrete feature-related reason to stop there,
as to avoid having more distinct behaviors than we have to in this area.
Amit Langote
Discussion: <[email protected]>
M src/backend/catalog/heap.c
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Fix copy-pasto in comment.
commit : 6f020925223826cf457d8048b085b57674c525b7
author : Heikki Linnakangas <[email protected]>
date : Wed, 12 Oct 2016 12:07:54 +0300
committer: Heikki Linnakangas <[email protected]>
date : Wed, 12 Oct 2016 12:07:54 +0300
Amit Langote
M src/include/catalog/pg_cast.h
In PQsendQueryStart(), avoid leaking any left-over async result.
commit : 7397f62e7fd9a90bba8c8dc8d61c569a41040762
author : Tom Lane <[email protected]>
date : Mon, 10 Oct 2016 10:35:58 -0400
committer: Tom Lane <[email protected]>
date : Mon, 10 Oct 2016 10:35:58 -0400
Ordinarily there would not be an async result sitting around at this
point, but it appears that in corner cases there can be. Considering
all the work we're about to launch, it's hardly going to cost anything
noticeable to check.
It's been like this forever, so back-patch to all supported branches.
Report: <CAD-Qf1eLUtBOTPXyFQGW-4eEsop31tVVdZPu4kL9pbQ6tJPO8g@mail.gmail.com>
M src/interfaces/libpq/fe-exec.c
Fix two bugs in merging of inherited CHECK constraints.
commit : a54faa6591df7a1ea15078c4979f882a596ae480
author : Tom Lane <[email protected]>
date : Sat, 8 Oct 2016 19:29:28 -0400
committer: Tom Lane <[email protected]>
date : Sat, 8 Oct 2016 19:29:28 -0400
Historically, we've allowed users to add a CHECK constraint to a child
table and then add an identical CHECK constraint to the parent. This
results in "merging" the two constraints so that the pre-existing
child constraint ends up with both conislocal = true and coninhcount > 0.
However, if you tried to do it in the other order, you got a duplicate
constraint error. This is problematic for pg_dump, which needs to issue
separated ADD CONSTRAINT commands in some cases, but has no good way to
ensure that the constraints will be added in the required order.
And it's more than a bit arbitrary, too. The goal of complaining about
duplicated ADD CONSTRAINT commands can be served if we reject the case of
adding a constraint when the existing one already has conislocal = true;
but if it has conislocal = false, let's just make the ADD CONSTRAINT set
conislocal = true. In this way, either order of adding the constraints
has the same end result.
Another problem was that the code allowed creation of a parent constraint
marked convalidated that is merged with a child constraint that is
!convalidated. In this case, an inheritance scan of the parent table could
emit some rows violating the constraint condition, which would be an
unexpected result given the marking of the parent constraint as validated.
Hence, forbid merging of constraints in this case. (Note: valid child and
not-valid parent seems fine, so continue to allow that.)
Per report from Benedikt Grundmann. Back-patch to 9.2 where we introduced
possibly-not-valid check constraints. The second bug obviously doesn't
apply before that, and I think the first doesn't either, because pg_dump
only gets into this situation when dealing with not-valid constraints.
Report: <CADbMkNPT-Jz5PRSQ4RbUASYAjocV_KHUWapR%2Bg8fNvhUAyRpxA%40mail.gmail.com>
Discussion: <[email protected]>
M src/backend/catalog/heap.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/inherit.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/sql/inherit.sql
Remove user_relns() SRF from regression tests.
commit : 7ca8895e48682061583f37bb46afc2aa2591875a
author : Tom Lane <[email protected]>
date : Sat, 8 Oct 2016 18:43:01 -0400
committer: Tom Lane <[email protected]>
date : Sat, 8 Oct 2016 18:43:01 -0400
Back-patch commit 0dba54f1666ead71c54ce100b39efda67596d297 into the older
branches. This test is almost as much of a patching hazard there as it is
in HEAD, and it has no more reason to be needed than it does in HEAD.
I went back as far as 9.2; I judged 9.1 not worth the trouble since
it's on the verge of being EOL'd.
M src/test/regress/input/create_function_2.source
M src/test/regress/input/misc.source
M src/test/regress/output/create_function_2.source
M src/test/regress/output/misc.source
Clear OpenSSL error queue after failed X509_STORE_load_locations() call.
commit : 5d5dc6f68aeff20822ae28fae6c51f634c878278
author : Heikki Linnakangas <[email protected]>
date : Fri, 7 Oct 2016 12:53:49 +0300
committer: Heikki Linnakangas <[email protected]>
date : Fri, 7 Oct 2016 12:53:49 +0300
Leaving the error in the error queue used to be harmless, because the
X509_STORE_load_locations() call used to be the last step in
initialize_SSL(), and we would clear the queue before the next
SSL_connect() call. But previous commit moved things around. The symptom
was that if a CRL file was not found, and one of the subsequent
initialization steps, like loading the client certificate or private key,
failed, we would incorrectly print the "no such file" error message from
the earlier X509_STORE_load_locations() call as the reason.
Backpatch to all supported versions, like the previous patch.
M src/interfaces/libpq/fe-secure.c
Don't share SSL_CTX between libpq connections.
commit : e7bb327e347212172b7db16af6721c39090aa5c5
author : Heikki Linnakangas <[email protected]>
date : Fri, 7 Oct 2016 12:20:39 +0300
committer: Heikki Linnakangas <[email protected]>
date : Fri, 7 Oct 2016 12:20:39 +0300
There were several issues with the old coding:
1. There was a race condition, if two threads opened a connection at the
same time. We used a mutex around SSL_CTX_* calls, but that was not
enough, e.g. if one thread SSL_CTX_load_verify_locations() with one
path, and another thread set it with a different path, before the first
thread got to establish the connection.
2. Opening two different connections, with different sslrootcert settings,
seemed to fail outright with "SSL error: block type is not 01". Not sure
why.
3. We created the SSL object, before calling SSL_CTX_load_verify_locations
and SSL_CTX_use_certificate_chain_file on the SSL context. That was
wrong, because the options set on the SSL context are propagated to the
SSL object, when the SSL object is created. If they are set after the
SSL object has already been created, they won't take effect until the
next connection. (This is bug #14329)
At least some of these could've been fixed while still using a shared
context, but it would've been more complicated and error-prone. To keep
things simple, let's just use a separate SSL context for each connection,
and accept the overhead.
Backpatch to all supported versions.
Report, analysis and test case by Kacper Zuk.
Discussion: <[email protected]>
M src/interfaces/libpq/fe-secure.c
Include <sys/select.h> where needed
commit : e0da2c64197d1a314e404ee2b80f71cd344b974e
author : Alvaro Herrera <[email protected]>
date : Tue, 27 Sep 2016 01:05:21 -0300
committer: Alvaro Herrera <[email protected]>
date : Tue, 27 Sep 2016 01:05:21 -0300
<sys/select.h> is required by POSIX.1-2001 to get the prototype of
select(2), but nearly no systems enforce that because older standards
let you get away with including some other headers. Recent OpenBSD
hacking has removed that frail touch of friendliness, however, which
broke some compiles; fix all the way back to 9.1 by adding the required
standard. Only vacuumdb.c was reported to fail, but it seems easier to
fix the whole lot in a fell swoop.
Per bug #14334 by Sean Farrell.
M src/backend/libpq/auth.c
M src/backend/postmaster/pgstat.c
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/receivelog.c
M src/port/pgsleep.c
M src/test/examples/testlibpq2.c
Document has_type_privilege().
commit : d3af3c01a0034b0721dd20b7a9e7d1b436c05357
author : Tom Lane <[email protected]>
date : Mon, 26 Sep 2016 11:50:36 -0400
committer: Tom Lane <[email protected]>
date : Mon, 26 Sep 2016 11:50:36 -0400
Evidently an oversight in commit 729205571. Back-patch to 9.2 where
privileges for types were introduced.
Report: <[email protected]>
M doc/src/sgml/func.sgml
Doc: fix examples of # operators so they actually work.
commit : ded7c558d07b13874e1be165d21c290732e62a21
author : Tom Lane <[email protected]>
date : Fri, 23 Sep 2016 14:22:07 -0400
committer: Tom Lane <[email protected]>
date : Fri, 23 Sep 2016 14:22:07 -0400
These worked as-is until around 7.0, but fail in newer versions because
there are more operators named "#". Besides it's a bit inconsistent that
only two of the examples on this page lack type names on their constants.
Report: <[email protected]>
M doc/src/sgml/func.sgml
Fix incorrect logic for excluding range constructor functions in pg_dump.
commit : 53b29d986468a9eac6fcc8fddfce4da209b4f6a2
author : Tom Lane <[email protected]>
date : Fri, 23 Sep 2016 13:49:27 -0400
committer: Tom Lane <[email protected]>
date : Fri, 23 Sep 2016 13:49:27 -0400
Faulty AND/OR nesting in the WHERE clause of getFuncs' SQL query led to
dumping range constructor functions if they are part of an extension
and we're in binary-upgrade mode. Actually, we don't want to dump them
separately even then, since CREATE TYPE AS RANGE will create the range's
constructor functions regardless. Per report from Andrew Dunstan.
It looks like this mistake was introduced by me, in commit b985d4877, in
perhaps-overzealous refactoring to reduce code duplication. I'm suitably
embarrassed.
Report: <[email protected]>
M src/bin/pg_dump/pg_dump.c
Be sure to rewind the tuplestore read pointer in non-leader CTEScan nodes.
commit : 8552f9b903a099d82763460cb7ca28715d0ad2bb
author : Tom Lane <[email protected]>
date : Thu, 22 Sep 2016 11:34:44 -0400
committer: Tom Lane <[email protected]>
date : Thu, 22 Sep 2016 11:34:44 -0400
ExecInitCteScan supposed that it didn't have to do anything to the extra
tuplestore read pointer it gets from tuplestore_alloc_read_pointer.
However, it needs this read pointer to be positioned at the start of the
tuplestore, while tuplestore_alloc_read_pointer is actually defined as
cloning the current position of read pointer 0. In normal situations
that accidentally works because we initialize the whole plan tree at once,
before anything gets read. But it fails in an EvalPlanQual recheck, as
illustrated in bug #14328 from Dima Pavlov. To fix, just forcibly rewind
the pointer after tuplestore_alloc_read_pointer. The cost of doing so is
negligible unless the tuplestore is already in TSS_READFILE state, which
wouldn't happen in normal cases. We could consider altering tuplestore's
API to make that case cheaper, but that would make for a more invasive
back-patch and it doesn't seem worth it.
This has been broken probably for as long as we've had CTEs, so back-patch
to all supported branches.
Discussion: <[email protected]>
M src/backend/executor/nodeCtescan.c
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec
doc: Fix documentation to match actual make output
commit : 775c5502a86ee4c599b8547809659c086dae1bc8
author : Peter Eisentraut <[email protected]>
date : Tue, 20 Sep 2016 12:00:00 -0400
committer: Peter Eisentraut <[email protected]>
date : Tue, 20 Sep 2016 12:00:00 -0400
based on patch from Takeshi Ideriha <[email protected]>
M doc/src/sgml/installation.sgml
doc: Correct ALTER USER MAPPING example
commit : d38649a103590f2f5de62634d573359f03298a23
author : Peter Eisentraut <[email protected]>
date : Tue, 20 Sep 2016 12:00:00 -0400
committer: Peter Eisentraut <[email protected]>
date : Tue, 20 Sep 2016 12:00:00 -0400
The existing example threw an error.
From: gabrielle <[email protected]>
M doc/src/sgml/ref/alter_user_mapping.sgml
Fix ecpg -? option on Windows, add -V alias for --version.
commit : a4a3fac169e06b9297fe5b6ea947d47d2faf0145
author : Heikki Linnakangas <[email protected]>
date : Sun, 18 Sep 2016 13:46:32 +0300
committer: Heikki Linnakangas <[email protected]>
date : Sun, 18 Sep 2016 13:46:32 +0300
This makes the -? and -V options work consistently with other binaries.
--help and --version are now only recognized as the first option, i.e.
"ecpg --foobar --help" no longer prints the help, but that's consistent
with most of our other binaries, too.
Backpatch to all supported versions.
Haribabu Kommi
Discussion: <CAJrrPGfnRXvmCzxq6Dy=stAWebfNHxiL+Y_z7uqksZUCkW_waQ@mail.gmail.com>
M src/interfaces/ecpg/preproc/ecpg.c
Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL
commit : eaf6fe7fae390735ddeb9c9bbdebc54918fb416b
author : Simon Riggs <[email protected]>
date : Fri, 9 Sep 2016 11:45:40 +0100
committer: Simon Riggs <[email protected]>
date : Fri, 9 Sep 2016 11:45:40 +0100
lazy_truncate_heap() was waiting for
VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds
not milliseconds as originally intended.
Found by code inspection.
Simon Riggs
M src/backend/commands/vacuumlazy.c
Fix mdtruncate() to close fd.c handle of deleted segments.
commit : f5462dedb70417f57e76b4f90d68d7d099e5b046
author : Andres Freund <[email protected]>
date : Thu, 8 Sep 2016 16:51:09 -0700
committer: Andres Freund <[email protected]>
date : Thu, 8 Sep 2016 16:51:09 -0700
mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting
it. That lead to a fd.c handle to a truncated file being kept open until
backend exit.
The issue appears to have been introduced way back in 1a5c450f3024ac5,
before that the handle was closed inside FileUnlink().
The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE
for temporary tables, truncate files in place (i.e. TRUNCATE itself is
not affected), and the relation has to be bigger than 1GB. The
consequences of a leaked fd.c handle aren't severe either.
Discussion: <[email protected]>
Backpatch: all supported releases
M src/backend/storage/smgr/md.c
Add regression test coverage for non-default timezone abbreviation sets.
commit : 942ad33b20b7b57290902463dea3c460f5289ea8
author : Tom Lane <[email protected]>
date : Sun, 4 Sep 2016 20:02:16 -0400
committer: Tom Lane <[email protected]>
date : Sun, 4 Sep 2016 20:02:16 -0400
After further reflection about the mess cleaned up in commit 39b691f25,
I decided the main bit of test coverage that was still missing was to
check that the non-default abbreviation-set files we supply are usable.
Add that.
Back-patch to supported branches, just because it seems like a good
idea to keep this all in sync.
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamptz.sql
M src/timezone/README
Remove vestigial references to "zic" in favor of "IANA database".
commit : 88c3f56f0986f4a9f2471fb2eb33424fa6954679
author : Tom Lane <[email protected]>
date : Sun, 4 Sep 2016 19:42:08 -0400
committer: Tom Lane <[email protected]>
date : Sun, 4 Sep 2016 19:42:08 -0400
Commit b2cbced9e instituted a policy of referring to the timezone database
as the "IANA timezone database" in our user-facing documentation.
Propagate that wording into a couple of places that were still using "zic"
to refer to the database, which is definitely not right (zic is the
compilation tool, not the data).
Back-patch, not because this is very important in itself, but because
we routinely cherry-pick updates to the tznames files and I don't want
to risk future merge failures.
M src/timezone/tznames/Africa.txt
M src/timezone/tznames/America.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Australia
M src/timezone/tznames/Australia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Etc.txt
M src/timezone/tznames/Europe.txt
M src/timezone/tznames/Pacific.txt
M src/tools/RELEASE_CHANGES
Don't require dynamic timezone abbreviations to match underlying time zone.
commit : 1195b8efe6fdffac7d4999e6be3e361aac32d724
author : Tom Lane <[email protected]>
date : Fri, 2 Sep 2016 17:29:32 -0400
committer: Tom Lane <[email protected]>
date : Fri, 2 Sep 2016 17:29:32 -0400
Previously, we threw an error if a dynamic timezone abbreviation did not
match any abbreviation recorded in the referenced IANA time zone entry.
That seemed like a good consistency check at the time, but it turns out
that a number of the abbreviations in the IANA database are things that
Olson and crew made up out of whole cloth. Their current policy is to
remove such names in favor of using simple numeric offsets. Perhaps
unsurprisingly, a lot of these made-up abbreviations have varied in meaning
over time, which meant that our commit b2cbced9e and later changes made
them into dynamic abbreviations. So with newer IANA database versions
that don't mention these abbreviations at all, we fail, as reported in bug
#14307 from Neil Anderson. It's worse than just a few unused-in-the-wild
abbreviations not working, because the pg_timezone_abbrevs view stops
working altogether (since its underlying function tries to compute the
whole view result in one call).
We considered deleting these abbreviations from our abbreviations list, but
the problem with that is that we can't stay ahead of possible future IANA
changes. Instead, let's leave the abbreviations list alone, and treat any
"orphaned" dynamic abbreviation as just meaning the referenced time zone.
It will behave a bit differently than it used to, in that you can't any
longer override the zone's standard vs. daylight rule by using the "wrong"
abbreviation of a pair, but that's better than failing entirely. (Also,
this solution can be interpreted as adding a small new feature, which is
that any abbreviation a user wants can be defined as referencing a time
zone name.)
Back-patch to all supported branches, since this problem affects all
of them when using tzdata 2016f or newer.
Report: <[email protected]>
Discussion: <[email protected]>
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/datetime.sgml
M src/backend/utils/adt/datetime.c
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamptz.sql
Suppress GCC 6 warning about self-comparison
commit : b9ac11a298b22d773bff7939e9db165baf28505b
author : Tom Lane <[email protected]>
date : Thu, 1 Sep 2016 12:48:06 -0400
committer: Tom Lane <[email protected]>
date : Thu, 1 Sep 2016 12:48:06 -0400
Back-patch commit a2fd62dd53fb606dee69e0f4eb12289c87f5c8b1
into older branches. Per complaint from Pavel Stehule.
M src/port/path.c
Prevent starting a standalone backend with standby_mode on.
commit : 823df401d1840a6f5e94d5f725ccf03317cc1176
author : Tom Lane <[email protected]>
date : Wed, 31 Aug 2016 08:52:13 -0400
committer: Tom Lane <[email protected]>
date : Wed, 31 Aug 2016 08:52:13 -0400
This can't really work because standby_mode expects there to be more
WAL arriving, which there will not ever be because there's no WAL
receiver process to fetch it. Moreover, if standby_mode is on then
hot standby might also be turned on, causing even more strangeness
because that expects read-only sessions to be executing in parallel.
Bernd Helmle reported a case where btree_xlog_delete_get_latestRemovedXid
got confused, but rather than band-aiding individual problems it seems
best to prevent getting anywhere near this state in the first place.
Back-patch to all supported branches.
In passing, also fix some omissions of errcodes in other ereport's in
readRecoveryCommandFile().
Michael Paquier (errcode hacking by me)
Discussion: <[email protected]>
M src/backend/access/transam/xlog.c
Fix instability in parallel regression tests.
commit : da14d46705b31d2313ab97706008cfd909fc8627
author : Tom Lane <[email protected]>
date : Thu, 25 Aug 2016 09:57:09 -0400
committer: Tom Lane <[email protected]>
date : Thu, 25 Aug 2016 09:57:09 -0400
Commit f0c7b789a added a test case in case.sql that creates and then drops
both an '=' operator and the type it's for. Given the right timing, that
can cause a "cache lookup failed for type" failure in concurrent sessions,
which see the '=' operator as a potential match for '=' in a query, but
then the type is gone by the time they inquire into its properties.
It might be nice to make that behavior more robust someday, but as a
back-patchable solution, adjust the new test case so that the operator
is never visible to other sessions. Like the previous commit, back-patch
to all supported branches.
Discussion: <[email protected]>
M src/test/regress/expected/case.out
M src/test/regress/sql/case.sql
Fix improper repetition of previous results from a hashed aggregate.
commit : 23766389746db981626e55518d29001bae3181a2
author : Tom Lane <[email protected]>
date : Wed, 24 Aug 2016 14:37:51 -0400
committer: Tom Lane <[email protected]>
date : Wed, 24 Aug 2016 14:37:51 -0400
ExecReScanAgg's check for whether it could re-use a previously calculated
hashtable neglected the possibility that the Agg node might reference
PARAM_EXEC Params that are not referenced by its input plan node. That's
okay if the Params are in upper tlist or qual expressions; but if one
appears in aggregate input expressions, then the hashtable contents need
to be recomputed when the Param's value changes.
To avoid unnecessary performance degradation in the case of a Param that
isn't within an aggregate input, add logic to the planner to determine
which Params are within aggregate inputs. This requires a new field in
struct Agg, but fortunately we never write plans to disk, so this isn't
an initdb-forcing change.
Per report from Jeevan Chalke. This has been broken since forever,
so back-patch to all supported branches.
Andrew Gierth, with minor adjustments by me
Report: <CAM2+6=VY8ykfLT5Q8vb9B6EbeBk-NGuLbT6seaQ+Fq4zXvrDcA@mail.gmail.com>
M src/backend/executor/nodeAgg.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/subselect.c
M src/include/nodes/plannodes.h
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Update Windows timezone mapping from Windows 7 and 10
commit : 35982db498bbe9a802ea769723d3248b5797b01a
author : Magnus Hagander <[email protected]>
date : Thu, 18 Aug 2016 12:32:42 +0200
committer: Magnus Hagander <[email protected]>
date : Thu, 18 Aug 2016 12:32:42 +0200
This adds a couple of new timezones that are present in the newer
versions of Windows. It also updates comments to reference UTC rather
than GMT, as this change has been made in Windows.
Michael Paquier
M src/bin/initdb/findtimezone.c
Fix -e option in contrib/intarray/bench/bench.pl.
commit : 60bb1bb1224dc5c6d8dd8f5829f354ace74aba18
author : Tom Lane <[email protected]>
date : Wed, 17 Aug 2016 15:51:11 -0400
committer: Tom Lane <[email protected]>
date : Wed, 17 Aug 2016 15:51:11 -0400
As implemented, -e ran an EXPLAIN but then discarded the output, which
certainly seems pointless. Make it print to stdout instead. It's been
like that forever, so back-patch to all supported branches.
Daniel Gustafsson, reviewed by Andreas Scherbaum
Patch: <[email protected]>
M contrib/intarray/bench/bench.pl
Remove bogus dependencies on NUMERIC_MAX_PRECISION.
commit : 9d5bf77b59e618399762d718248d580726c99f3c
author : Tom Lane <[email protected]>
date : Sun, 14 Aug 2016 15:06:02 -0400
committer: Tom Lane <[email protected]>
date : Sun, 14 Aug 2016 15:06:02 -0400
NUMERIC_MAX_PRECISION is a purely arbitrary constraint on the precision
and scale you can write in a numeric typmod. It might once have had
something to do with the allowed range of a typmod-less numeric value,
but at least since 9.1 we've allowed, and documented that we allowed,
any value that would physically fit in the numeric storage format;
which is something over 100000 decimal digits, not 1000.
Hence, get rid of numeric_in()'s use of NUMERIC_MAX_PRECISION as a limit
on the allowed range of the exponent in scientific-format input. That was
especially silly in view of the fact that you can enter larger numbers as
long as you don't use 'e' to do it. Just constrain the value enough to
avoid localized overflow, and let make_result be the final arbiter of what
is too large. Likewise adjust ecpg's equivalent of this code.
Also get rid of numeric_recv()'s use of NUMERIC_MAX_PRECISION to limit the
number of base-NBASE digits it would accept. That created a dump/restore
hazard for binary COPY without doing anything useful; the wire-format
limit on number of digits (65535) is about as tight as we would want.
In HEAD, also get rid of pg_size_bytes()'s unnecessary intimacy with what
the numeric range limit is. That code doesn't exist in the back branches.
Per gripe from Aravind Kumar. Back-patch to all supported branches,
since they all contain the documentation claim about allowed range of
NUMERIC (cf commit cabf5d84b).
Discussion: <[email protected]>
M src/backend/utils/adt/numeric.c
M src/include/utils/numeric.h
M src/interfaces/ecpg/pgtypeslib/numeric.c
Fix regression test parallel-make hazard.
commit : 8c44731acb4c45c8756e2f34e86b3f6844ed45bc
author : Tom Lane <[email protected]>
date : Fri, 12 Aug 2016 20:51:59 -0400
committer: Tom Lane <[email protected]>
date : Fri, 12 Aug 2016 20:51:59 -0400
Back-patch 9.4-era commit 384f933046dc9e9a2b416f5f7b3be30b93587c63 into
the previous branches. Although that was only advertised as repairing a
problem with missed header-file dependencies, it turns out to also be
important for parallel make safety. The previous coding allowed two
independent make jobs to get launched concurrently in contrib/spi.
Normally this would be OK, because they are building independent targets;
but if --enable-depend is in use, it's unsafe, because one make run might
try to read a .deps file that the other one is in process of rewriting.
This is evidently the cause of buildfarm member francolin's recent failure
in the 9.2 branch. I believe this patch will result in only one subsidiary
make run, making it safe(r).
Report: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=francolin&dt=2016-08-12%2017%3A12%3A52
M src/test/regress/GNUmakefile
Fix inappropriate printing of never-measured times in EXPLAIN.
commit : ceb005319ac36fe28e252b13d24de6cb857d5943
author : Tom Lane <[email protected]>
date : Fri, 12 Aug 2016 12:13:04 -0400
committer: Tom Lane <[email protected]>
date : Fri, 12 Aug 2016 12:13:04 -0400
EXPLAIN (ANALYZE, TIMING OFF) would print an elapsed time of zero for
a trigger function, because no measurement has been taken but it printed
the field anyway. This isn't what EXPLAIN does elsewhere, so suppress it.
In the same vein, EXPLAIN (ANALYZE, BUFFERS) with non-text output format
would print buffer I/O timing numbers even when no measurement has been
taken because track_io_timing is off. That seems not per policy, either,
so change it.
Back-patch to 9.2 where these features were introduced.
Maksim Milyutin
Discussion: <[email protected]>
M src/backend/commands/explain.c
Doc: write some for adminpack.
commit : 0d762ff2c02dafcfe781ac3ef77111622a245f18
author : Tom Lane <[email protected]>
date : Wed, 10 Aug 2016 21:39:50 -0400
committer: Tom Lane <[email protected]>
date : Wed, 10 Aug 2016 21:39:50 -0400
Previous contents of adminpack.sgml were rather far short of project norms.
Not to mention being outright wrong about the signature of pg_file_read().
M doc/src/sgml/adminpack.sgml
Fix typo
commit : cbae4ab8e6cf4d5c283fcceab980dd281e4714f8
author : Peter Eisentraut <[email protected]>
date : Tue, 9 Aug 2016 19:07:24 -0400
committer: Peter Eisentraut <[email protected]>
date : Tue, 9 Aug 2016 19:07:24 -0400
M contrib/pgcrypto/px.c
Doc: clarify description of CREATE/ALTER FUNCTION ... SET FROM CURRENT.
commit : be1d75ea23ee020d0c5e27195a01d7678aa1b5ef
author : Tom Lane <[email protected]>
date : Tue, 9 Aug 2016 13:39:24 -0400
committer: Tom Lane <[email protected]>
date : Tue, 9 Aug 2016 13:39:24 -0400
Per discussion with David Johnston.
M doc/src/sgml/ref/alter_function.sgml
M doc/src/sgml/ref/create_function.sgml