Stamp 9.5.17.
commit : b221b78f83f5bc337b596170d70ab0a9d72a2951
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 May 2019 16:52:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 May 2019 16:52:44 -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
Last-minute updates for release notes.
commit : 1760514e73e942dcb73231b6d65f6c2ef210c7da
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 May 2019 12:45:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 May 2019 12:45:59 -0400
Security: CVE-2019-10129, CVE-2019-10130
M doc/src/sgml/release-9.5.sgml
Translation updates
commit : 1fa14a1a24994bc1de6501952f63b8d8807bf225
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 6 May 2019 14:56:15 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 6 May 2019 14:56:15 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 499248e4e6cd0dea44450fb13352e7a03fccb00e
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/ru.po
M src/bin/initdb/po/es.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_config/po/es.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/es.po
M src/bin/pg_rewind/po/es.po
M src/bin/psql/po/es.po
M src/bin/scripts/po/es.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/es.po
M src/pl/plperl/po/es.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpython/po/es.po
M src/pl/tcl/po/es.po
Use checkAsUser for selectivity estimator checks, if it's set.
commit : 01256815a6304c114c47c2ca70fb752a3ec81ac3
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 12:01:44 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 12:01:44 +0100
In examine_variable() and examine_simple_variable(), when checking the
user's table and column privileges to determine whether to grant
access to the pg_statistic data, use checkAsUser for the privilege
checks, if it's set. This will be the case if we're accessing the
table via a view, to indicate that we should perform privilege checks
as the view owner rather than the current user.
This change makes this planner check consistent with the check in the
executor, so the planner will be able to make use of statistics if the
table is accessible via the view. This fixes a performance regression
introduced by commit e2d4ef8de8, which affects queries against
non-security barrier views in the case where the user doesn't have
privileges on the underlying table, but the view owner does.
Note that it continues to provide the same safeguards controlling
access to pg_statistic for direct table access (in which case
checkAsUser won't be set) and for security barrier views, because of
the nearby checks on rte->security_barrier and rte->securityQuals.
Back-patch to all supported branches because e2d4ef8de8 was.
Dean Rasheed, reviewed by Jonathan Katz and Stephen Frost.
M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql
Fix security checks for selectivity estimation functions with RLS.
commit : 93c36145ad10f3b4795d8e411720ae55180ad274
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 11:46:33 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 11:46:33 +0100
In commit e2d4ef8de8, security checks were added to prevent
user-supplied operators from running over data from pg_statistic
unless the user has table or column privileges on the table, or the
operator is leakproof. For a table with RLS, however, checking for
table or column privileges is insufficient, since that does not
guarantee that the user has permission to view all of the column's
data.
Fix this by also checking for securityQuals on the RTE, and insisting
that the operator be leakproof if there are any. Thus the
leakproofness check will only be skipped if there are no securityQuals
and the user has table or column privileges on the table -- i.e., only
if we know that the user has access to all the data in the column.
Back-patch to 9.5 where RLS was added.
Dean Rasheed, reviewed by Jonathan Katz and Stephen Frost.
Security: CVE-2019-10130
M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Remove reindex_catalog test from test schedules.
commit : 8439589bc7e74e4687797da8c0e88455decf5463
author : Andres Freund <andres@anarazel.de>
date : Sun, 5 May 2019 23:31:58 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 5 May 2019 23:31:58 -0700
As the test currently causes occasional deadlocks (due to the schema
cleanup from previous sessions potentially still running), and the
patch from f912d7dec2 has gotten a fair bit of buildfarm coverage,
remove the test from the test schedules. There's a set of minor
releases coming up.
Leave the tests in place, so it can manually be run using EXTRA_TESTS.
For now also leave it in master, as there's no imminent release, and
there's plenty (re-)index related work in 12. But we'll have to
disable it before long there too, unless somebody comes up with simple
enough fixes for the deadlock (I'm about to post a vague idea to the
list).
Discussion: https://postgr.es/m/4622.1556982247@sss.pgh.pa.us
Backpatch: 9.4-11 (no master!)
M src/test/regress/expected/reindex_catalog.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/reindex_catalog.sql
Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22.
commit : 0b41329a3a539c879e0c6731a0830778338777ed
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 14:57:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 14:57:16 -0400
M doc/src/sgml/release-9.5.sgml
Fix reindexing of pg_class indexes some more.
commit : d18ef690509f94d33d11b35b63e39be5f857dfae
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 May 2019 19:11:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 May 2019 19:11:28 -0400
Commits 3dbb317d3 et al failed under CLOBBER_CACHE_ALWAYS testing.
Investigation showed that to reindex pg_class_oid_index, we must
suppress accesses to the index (via SetReindexProcessing) before we call
RelationSetNewRelfilenode, or at least before we do CommandCounterIncrement
therein; otherwise, relcache reloads happening within the CCI may try to
fetch pg_class rows using the index's new relfilenode value, which is as
yet an empty file.
Of course, the point of 3dbb317d3 was that that ordering didn't work
either, because then RelationSetNewRelfilenode's own update of the index's
pg_class row cannot access the index, should it need to.
There are various ways we might have got around that, but Andres Freund
came up with a brilliant solution: for a mapped index, we can really just
skip the pg_class update altogether. The only fields it was actually
changing were relpages etc, but it was just setting them to zeroes which
is useless make-work. (Correct new values will be installed at the end
of index build.) All pg_class indexes are mapped and probably always will
be, so this eliminates the problem by removing work rather than adding it,
always a pleasant outcome. Having taught RelationSetNewRelfilenode to do
it that way, we can revert the code reordering in reindex_index. (But
I left the moved setup code where it was; there seems no reason why it
has to run without use of the old index. If you're trying to fix a
busted pg_class index, you'll have had to disable system index use
altogether to get this far.)
Moreover, this means we don't need RelationSetIndexList at all, because
reindex_relation's hacking to make "REINDEX TABLE pg_class" work is
likewise now unnecessary. We'll leave that code in place in the back
branches, but a follow-on patch will remove it in HEAD.
In passing, do some minor cleanup for commit 5c1560606 (in HEAD only),
notably removing a duplicate newrnode assignment.
Patch by me, using a core idea due to Andres Freund. Back-patch to all
supported branches, as 3dbb317d3 was.
Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us
M src/backend/catalog/index.c
M src/backend/utils/cache/relcache.c
Run catalog reindexing test from 3dbb317d32 serially, to avoid deadlocks.
commit : 3630c6bfad94b203b5b4cfbb04de64f029715959
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700
The tests turn out to cause deadlocks in some circumstances. Fairly
reproducibly so with -DRELCACHE_FORCE_RELEASE
-DCATCACHE_FORCE_RELEASE. Some of the deadlocks may be hard to fix
without disproportionate measures, but others probably should be fixed
- but not in 12.
We discussed removing the new tests until we can fix the issues
underlying the deadlocks, but results from buildfarm animal
markhor (which runs with CLOBBER_CACHE_ALWAYS) indicates that there
might be a more severe, as of yet undiagnosed, issue (including on
stable branches) with reindexing catalogs. The failure is:
ERROR: could not read block 0 in file "base/16384/28025": read only 0 of 8192 bytes
Therefore it seems advisable to keep the tests.
It's not certain that running the tests in isolation removes the risk
of deadlocks. It's possible that additional locks are needed to
protect against a concurrent auto-analyze or such.
Per discussion with Tom Lane.
Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us
Backpatch: 9.4-, like 3dbb317d3
M src/test/regress/expected/create_index.out
A src/test/regress/expected/reindex_catalog.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/create_index.sql
A src/test/regress/sql/reindex_catalog.sql
Fix unused variable compiler warning in !debug builds.
commit : 5409e359f81488056fb690c7aef0fd79d8a118d6
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700
Introduced in 3dbb317d3. Fix by using the new local variable in more
places.
Reported-By: Bruce Momjian (off-list)
Backpatch: 9.4-, like 3dbb317d3
M src/backend/catalog/indexing.c
Fix potential assertion failure when reindexing a pg_class index.
commit : 670a492c5f1bf74b098c200aa469db044ec06d6e
author : Andres Freund <andres@anarazel.de>
date : Mon, 29 Apr 2019 19:39:36 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 29 Apr 2019 19:39:36 -0700
When reindexing individual indexes on pg_class it was possible to
either trigger an assertion failure:
TRAP: FailedAssertion("!(!ReindexIsProcessingIndex(((index)->rd_id)))
That's because reindex_index() called SetReindexProcessing() - which
enables an asserts ensuring no index insertions happen into the index
- before calling RelationSetNewRelfilenode(). That not correct for
indexes on pg_class, because RelationSetNewRelfilenode() updates the
relevant pg_class row, which needs to update the indexes.
The are two reasons this wasn't noticed earlier. Firstly the bug
doesn't trigger when reindexing all of pg_class, as reindex_relation
has code "hiding" all yet-to-be-reindexed indexes. Secondly, the bug
only triggers when the the update to pg_class doesn't turn out to be a
HOT update - otherwise there's no index insertion to trigger the
bug. Most of the time there's enough space, making this bug hard to
trigger.
To fix, move RelationSetNewRelfilenode() to before the
SetReindexProcessing() (and, together with some other code, to outside
of the PG_TRY()).
To make sure the error checking intended by SetReindexProcessing() is
more robust, modify CatalogIndexInsert() to check
ReindexIsProcessingIndex() even when the update is a HOT update.
Also add a few regression tests for REINDEXing of system catalogs.
The last two improvements would have prevented some of the issues
fixed in 5c1560606dc4c from being introduced in the first place.
Reported-By: Michael Paquier
Diagnosed-By: Tom Lane and Andres Freund
Author: Andres Freund
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/20190418011430.GA19133@paquier.xyz
Backpatch: 9.4-, the bug is present in all branches
M contrib/test_decoding/expected/rewrite.out
M contrib/test_decoding/sql/rewrite.sql
M src/backend/catalog/index.c
M src/backend/catalog/indexing.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Correct the URL pointing to PL/R
commit : e729d0b8c7f3be459d56b984c979b79df4771200
author : Joe Conway <mail@joeconway.com>
date : Sat, 27 Apr 2019 09:28:06 -0400
committer: Joe Conway <mail@joeconway.com>
date : Sat, 27 Apr 2019 09:28:06 -0400
As pointed out by documentation comment, the URL for PL/R
needs to be updated to the correct current repository. Back-patch
to all supported branches.
M doc/src/sgml/external-projects.sgml
Portability fix for zic.c.
commit : b3904abb4d43f59749438735ab3ce3227e9b61b8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 21:20:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 21:20:11 -0400
Missed an inttypes.h dependency in previous patch. Per buildfarm.
M src/timezone/README
M src/timezone/zic.c
Sync our copy of the timezone library with IANA release tzcode2019a.
commit : 22ba955367aedb21566af171623ebbaadcb35ca1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 19:46:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 19:46:26 -0400
This corrects a small bug in zic that caused it to output an incorrect
year-2440 transition in the Africa/Casablanca zone.
More interestingly, zic has grown a "-r" option that limits the range of
zone transitions that it will put into the output files. That might be
useful to people who don't like the weird GMT offsets that tzdb likes
to use for very old dates. It appears that for dates before the cutoff
time specified with -r, zic will use the zone's standard-time offset
as of the cutoff time. So for example one might do
make install ZIC_OPTIONS='-r @-1893456000'
to cause all dates before 1910-01-01 to be treated as though 1910
standard time prevailed indefinitely far back. (Don't blame me for
the unfriendly way of specifying the cutoff time --- it's seconds
since or before the Unix epoch. You can use extract(epoch ...)
to calculate it.)
As usual, back-patch to all supported branches.
M src/timezone/Makefile
M src/timezone/README
M src/timezone/private.h
M src/timezone/tzfile.h
M src/timezone/zic.c
Update time zone data files to tzdata release 2019a.
commit : c1c76431c67cc0da16cae38741dc945daf92a5af
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 17:56:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 17:56:26 -0400
DST law changes in Palestine and Metlakatla.
Historical corrections for Israel.
Etc/UCT is now a backward-compatibility link to Etc/UTC, instead
of being a separate zone that generates the abbreviation "UCT",
which nowadays is typically a typo. Postgres will still accept
"UCT" as an input zone name, but it won't output it.
M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt
Fix some minor postmaster-state-machine issues.
commit : c7e38be4df4c116753a2e0f9dc1148e50177edd9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Apr 2019 14:15:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Apr 2019 14:15:45 -0400
In sigusr1_handler, don't ignore PMSIGNAL_ADVANCE_STATE_MACHINE based
on pmState. The restriction is unnecessary (PostmasterStateMachine
should work in any state), not future-proof (since it makes too many
assumptions about why the signal might be sent), and broken even today
because a race condition can make it necessary to respond to the signal
in PM_WAIT_READONLY state. The race condition seems unlikely, but
if it did happen, a hot-standby postmaster could fail to shut down
after receiving a smart-shutdown request.
In MaybeStartWalReceiver, don't clear the WalReceiverRequested flag
if the fork attempt fails. Leaving it set allows us to try
again in future iterations of the postmaster idle loop. (The startup
process would eventually send a fresh request signal, but this change
may allow us to retry the fork sooner.)
Remove an obsolete comment and unnecessary test in
PostmasterStateMachine's handling of PM_SHUTDOWN_2 state. It's not
possible to have a live walreceiver in that state, and AFAICT has not
been possible since commit 5e85315ea. This isn't a live bug, but the
false comment is quite confusing to readers.
In passing, rearrange sigusr1_handler's CheckPromoteSignal tests so that
we don't uselessly perform stat() calls that we're going to ignore the
results of.
Add some comments clarifying the behavior of MaybeStartWalReceiver;
I very nearly rearranged it in a way that'd reintroduce the race
condition fixed in e5d494d78. Mea culpa for not commenting that
properly at the time.
Back-patch to all supported branches. The PMSIGNAL_ADVANCE_STATE_MACHINE
change is the only one of even minor significance, but we might as well
keep this code in sync across branches.
Discussion: https://postgr.es/m/9001.1556046681@sss.pgh.pa.us
M src/backend/postmaster/postmaster.c
Fix detection of passwords hashed with MD5
commit : 20dbc84bd002c5ef2b5439ac29b6a5b24b0a3d69
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Apr 2019 09:05:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Apr 2019 09:05:30 +0900
This commit fixes an issue related to the way password verifiers hashed
with MD5 are detected, leading to possibly detect that plain passwords
are legit MD5 hashes. A MD5-hashed entry was checked based on if its
header uses "md5" and if the string length matches what is expected.
Unfortunately the code never checked if the hash only used hexadecimal
characters after the three-character prefix.
Fix 9.6 down to 9.4, where this code is present. This area of the code
has changed in 10 and upwards with the introduction of SCRAM, which led
to a different fix committed as of ccae190.
Reported-by: Tom Lane
Author: Michael Paquier
Reviewed-by: Jonathan Katz
Discussion: https://postgr.es/m/016deb6b-1f0a-8e9f-1833-a8675b170aa9@postgresql.org
Backpatch-through: 9.4
M src/include/libpq/md5.h
Repair assorted issues in locale data extraction.
commit : 74589026f79f68a0109200d4c7fa227f82e65c08
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Apr 2019 18:51:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Apr 2019 18:51:31 -0400
cache_locale_time (extraction of LC_TIME-related info) had never been
taught the lessons we previously learned about extraction of info related
to LC_MONETARY and LC_NUMERIC. Specifically, commit 95a777c61 taught
PGLC_localeconv() that data coming out of localeconv() was in an encoding
determined by the relevant locale, but we didn't realize that there's a
similar issue with strftime(). And commit a4930e7ca hardened
PGLC_localeconv() against errors occurring partway through, but failed
to do likewise for cache_locale_time(). So, rearrange the latter
function to perform encoding conversion and not risk failure while
it's got the locales set to temporary values.
This time around I also changed PGLC_localeconv() to treat it as FATAL
if it can't restore the previous settings of the locale values. There
is no reason (except possibly OOM) for that to fail, and proceeding with
the wrong locale values seems like a seriously bad idea --- especially
on Windows where we have to also temporarily change LC_CTYPE. Also,
protect against the possibility that we can't identify the codeset
reported for LC_MONETARY or LC_NUMERIC; rather than just failing,
try to validate the data without conversion.
The user-visible symptom this fixes is that if LC_TIME is set to a locale
name that implies an encoding different from the database encoding,
non-ASCII localized day and month names would be retrieved in the wrong
encoding, leading to either unexpected encoding-conversion error reports
or wrong output from to_char(). The other possible failure modes are
unlikely enough that we've not seen reports of them, AFAIK.
The encoding conversion problems do not manifest on Windows, since
we'd already created special-case code to handle that issue there.
Per report from Juan José Santamaría Flecha. Back-patch to all
supported versions.
Juan José Santamaría Flecha and Tom Lane
Discussion: https://postgr.es/m/CAC+AXB22So5aZm2vZe+MChYXec7gWfr-n-SK-iO091R0P_1Tew@mail.gmail.com
M src/backend/utils/adt/pg_locale.c
M src/test/regress/expected/collate.linux.utf8.out
M src/test/regress/sql/collate.linux.utf8.sql
postgresql.conf.sample: add proper defaults for include actions
commit : 475f07aa2e72422ecb2e3bfb283a7cf722cfc3b0
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 17 Apr 2019 18:12:10 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 17 Apr 2019 18:12:10 -0400
Previously, include actions include_dir, include_if_exists, and include
listed commented-out values which were not the defaults, which is
inconsistent with other entries. Instead, replace them with '', which
is the default value.
Reported-by: Emanuel Araújo
Discussion: https://postgr.es/m/CAMuTAkYMx6Q27wpELDR3_v9aG443y7ZjeXu15_+1nGUjhMWOJA@mail.gmail.com
Backpatch-through: 9.4
M src/backend/utils/misc/postgresql.conf.sample
docs: clarify pg_upgrade's recovery behavior
commit : dfdab98cdee892ac4a557161a9aaef5715901175
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 17 Apr 2019 18:01:01 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 17 Apr 2019 18:01:01 -0400
The previous paragraph trying to explain --check, --link, and no --link
modes and the various points of failure was too complex. Instead, use
bullet lists and sublists.
Reported-by: Daniel Gustafsson
Discussion: https://postgr.es/m/qtqiv7hI87s_Xvz5ZXHCaH-1-_AZGpIDJowzlRjF3-AbCr3RhSNydM_JCuJ8DE4WZozrtxhIWmyYTbv0syKyfGB6cYMQitp9yN-NZMm-oAo=@yesql.se
Backpatch-through: 9.4
M doc/src/sgml/ref/pgupgrade.sgml
Consistently test for in-use shared memory.
commit : c565de643167745c94ddeb0231c6de59ecf9da94
author : Noah Misch <noah@leadboat.com>
date : Fri, 12 Apr 2019 22:36:38 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 12 Apr 2019 22:36:38 -0700
postmaster startup scrutinizes any shared memory segment recorded in
postmaster.pid, exiting if that segment matches the current data
directory and has an attached process. When the postmaster.pid file was
missing, a starting postmaster used weaker checks. Change to use the
same checks in both scenarios. This increases the chance of a startup
failure, in lieu of data corruption, if the DBA does "kill -9 `head -n1
postmaster.pid` && rm postmaster.pid && pg_ctl -w start". A postmaster
will no longer stop if shmat() of an old segment fails with EACCES. A
postmaster will no longer recycle segments pertaining to other data
directories. That's good for production, but it's bad for integration
tests that crash a postmaster and immediately delete its data directory.
Such a test now leaks a segment indefinitely. No "make check-world"
test does that. win32_shmem.c already avoided all these problems. In
9.6 and later, enhance PostgresNode to facilitate testing. Back-patch
to 9.4 (all supported versions).
Reviewed (in earlier versions) by Daniel Gustafsson and Kyotaro HORIGUCHI.
Discussion: https://postgr.es/m/20190408064141.GA2016666@rfd.leadboat.com
M src/backend/port/sysv_shmem.c
M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/backend/storage/ipc/ipci.c
M src/backend/utils/init/postinit.c
M src/include/storage/ipc.h
M src/include/storage/pg_shmem.h
Fix off-by-one check that can lead to a memory overflow in ecpg.
commit : 67f6e645e7acf356abb1b914a1d8536708ec0f67
author : Michael Meskes <meskes@postgresql.org>
date : Thu, 11 Apr 2019 20:56:17 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Thu, 11 Apr 2019 20:56:17 +0200
Patch by Liu Huailing <liuhuailing@cn.fujitsu.com>
M src/interfaces/ecpg/preproc/pgc.l
doc: adjust libpq wording to be neither/nor
commit : d3cf886e314aa6f64a336dc447c68be33d63df34
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 11 Apr 2019 13:25:34 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 11 Apr 2019 13:25:34 -0400
Reported-by: postgresql@cohi.at
Discussion: https://postgr.es/m/155419437926.737.10876947446993402227@wrigleys.postgresql.org
Backpatch-through: 9.4
M doc/src/sgml/libpq.sgml
Fix backwards test in operator_precedence_warning logic.
commit : b9b7fe8ca452e95f0723e59c1b4b74723e07bc33
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Apr 2019 19:02:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Apr 2019 19:02:21 -0400
Warnings about unary minus might have been wrong. It's a bit
surprising that nobody noticed yet ... probably the precedence-warning
feature hasn't really been used much in the field.
Rikard Falkeborn
Discussion: https://postgr.es/m/CADRDgG6fzA8A2oeygUw4=o7ywo4kvz26NxCSgpq22nMD73Bx4Q@mail.gmail.com
M src/backend/parser/parse_expr.c
Define WIN32_STACK_RLIMIT throughout win32 and cygwin builds.
commit : 292e2000e19c5a38fd901b4764e26c638edeac11
author : Noah Misch <noah@leadboat.com>
date : Tue, 9 Apr 2019 08:25:39 -0700
committer: Noah Misch <noah@leadboat.com>
date : Tue, 9 Apr 2019 08:25:39 -0700
The MSVC build system already did this, and commit
617dc6d299c957e2784320382b3277ede01d9c63 used it in a second file.
Back-patch to 9.4, like that commit.
Discussion: https://postgr.es/m/CAA8=A7_1SWc3+3Z=-utQrQFOtrj_DeohRVt7diA2tZozxsyUOQ@mail.gmail.com
M src/backend/tcop/Makefile
M src/makefiles/Makefile.cygwin
M src/makefiles/Makefile.win32
Avoid "could not reattach" by providing space for concurrent allocation.
commit : 7a5677818556a2d3ab02a536c01955e90ddc1ea9
author : Noah Misch <noah@leadboat.com>
date : Mon, 8 Apr 2019 21:39:00 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 8 Apr 2019 21:39:00 -0700
We've long had reports of intermittent "could not reattach to shared
memory" errors on Windows. Buildfarm member dory fails that way when
PGSharedMemoryReAttach() execution overlaps with creation of a thread
for the process's "default thread pool". Fix that by providing a second
region to receive asynchronous allocations that would otherwise intrude
into UsedShmemSegAddr. In pgwin32_ReserveSharedMemoryRegion(), stop
trying to free reservations landing at incorrect addresses; the caller's
next step has been to terminate the affected process. Back-patch to 9.4
(all supported versions).
Reviewed by Tom Lane. He also did much of the prerequisite research;
see commit bcbf2346d69f6006f126044864dd9383d50d87b4.
Discussion: https://postgr.es/m/20190402135442.GA1173872@rfd.leadboat.com
M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/include/storage/pg_shmem.h
Fix improper interaction of FULL JOINs with lateral references.
commit : 2f78974e29bde06c265dec1332a8cc4c06bcda97
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Apr 2019 16:09:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Apr 2019 16:09:07 -0400
join_is_legal() needs to reject forming certain outer joins in cases
where that would lead the planner down a blind alley. However, it
mistakenly supposed that the way to handle full joins was to treat them
as applying the same constraints as for left joins, only to both sides.
That doesn't work, as shown in bug #15741 from Anthony Skorski: given
a lateral reference out of a join that's fully enclosed by a full join,
the code would fail to believe that any join ordering is legal, resulting
in errors like "failed to build any N-way joins".
However, we don't really need to consider full joins at all for this
purpose, because we effectively force them to be evaluated in syntactic
order, and that order is always legal for lateral references. Hence,
get rid of this broken logic for full joins and just ignore them instead.
This seems to have been an oversight in commit 7e19db0c0.
Back-patch to all supported branches, as that was.
Discussion: https://postgr.es/m/15741-276f1f464b3f40eb@postgresql.org
M src/backend/optimizer/path/joinrels.c
M src/test/regress/expected/rangefuncs.out
M src/test/regress/sql/rangefuncs.sql
Revert "Consistently test for in-use shared memory."
commit : 9ec582b64d69fcd103e8a3bc13a621ca376db921
author : Noah Misch <noah@leadboat.com>
date : Fri, 5 Apr 2019 00:00:52 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 5 Apr 2019 00:00:52 -0700
This reverts commits 2f932f71d9f2963bbd201129d7b971c8f5f077fd,
16ee6eaf80a40007a138b60bb5661660058d0422 and
6f0e190056fe441f7cf788ff19b62b13c94f68f3. The buildfarm has revealed
several bugs. Back-patch like the original commits.
Discussion: https://postgr.es/m/20190404145319.GA1720877@rfd.leadboat.com
M src/backend/port/sysv_shmem.c
M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/backend/storage/ipc/ipci.c
M src/backend/utils/init/postinit.c
M src/include/storage/ipc.h
M src/include/storage/pg_shmem.h
Fix some documentation in pg_rewind
commit : 1f63f69c43b5709cf6d8fe60be5e4f137c157316
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 5 Apr 2019 10:38:47 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 5 Apr 2019 10:38:47 +0900
A confusion which comes a lot from users is that it is necessary to
issue a checkpoint on a freshly-promoted standby so as its control file
has up-to-date timeline information which is used by pg_rewind to
validate the operation. Let's document that properly. This is
back-patched down to 9.5 where pg_rewind has been introduced.
Author: Michael Paquier
Reviewed-by: Magnus Hagander
Discussion: https://postgr.es/m/CABUevEz5bpvbwVsYCaSMV80CBZ5-82nkMzbb+Bu=h1m=rLdn=g@mail.gmail.com
Backpatch-through: 9.5
M doc/src/sgml/ref/pg_rewind.sgml
Silence -Wimplicit-fallthrough in sysv_shmem.c.
commit : e9559e7add5f91befb64f8a9e8c9e4a7d2074828
author : Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 23:23:35 -0700
committer: Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 23:23:35 -0700
Commit 2f932f71d9f2963bbd201129d7b971c8f5f077fd added code that elicits
a warning on buildfarm member flaviventris. Back-patch to 9.4, like
that commit.
Reported by Andres Freund.
Discussion: https://postgr.es/m/20190404020057.galelv7by75ekqrh@alap3.anarazel.de
M src/backend/port/sysv_shmem.c
Handle USE_MODULE_DB for all tests able to use an installed postmaster.
commit : 267d83c7d7d21b8ca3e2b99b231766ac050b8c93
author : Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 17:06:01 -0700
committer: Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 17:06:01 -0700
When $(MODULES) and $(MODULE_big) are empty, derive the database name
from the first element of $(REGRESS) instead of using a constant string.
When deriving the database name from $(MODULES), use its first element
instead of the entire list; the earlier approach would fail if any
multi-module directory had $(REGRESS) tests. Treat isolation suites and
src/pl correspondingly. Under USE_MODULE_DB=1, installcheck-world and
check-world no longer reuse any database name in a given postmaster.
Buildfarm members axolotl, mandrill and frogfish saw spurious "is being
accessed by other users" failures that would not have happened without
database name reuse. (The CountOtherDBBackends() 5s deadline expired
during DROP DATABASE; a backend for an earlier test suite had used the
same database name and had not yet exited.) Back-patch to 9.4 (all
supported versions), except bits pertaining to isolation suites.
Concept reviewed by Andrew Dunstan, Andres Freund and Tom Lane.
Discussion: https://postgr.es/m/20190401135213.GE891537@rfd.leadboat.com
M src/Makefile.global.in
M src/makefiles/pgxs.mk
Consistently test for in-use shared memory.
commit : e7f89a5dec0f95862d039d2ca9f0dcc3a1e20eb2
author : Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 17:03:46 -0700
committer: Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 17:03:46 -0700
postmaster startup scrutinizes any shared memory segment recorded in
postmaster.pid, exiting if that segment matches the current data
directory and has an attached process. When the postmaster.pid file was
missing, a starting postmaster used weaker checks. Change to use the
same checks in both scenarios. This increases the chance of a startup
failure, in lieu of data corruption, if the DBA does "kill -9 `head -n1
postmaster.pid` && rm postmaster.pid && pg_ctl -w start". A postmaster
will no longer recycle segments pertaining to other data directories.
That's good for production, but it's bad for integration tests that
crash a postmaster and immediately delete its data directory. Such a
test now leaks a segment indefinitely. No "make check-world" test does
that. win32_shmem.c already avoided all these problems. In 9.6 and
later, enhance PostgresNode to facilitate testing. Back-patch to 9.4
(all supported versions).
Reviewed by Daniel Gustafsson and Kyotaro HORIGUCHI.
Discussion: https://postgr.es/m/20130911033341.GD225735@tornado.leadboat.com
M src/backend/port/sysv_shmem.c
M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/backend/storage/ipc/ipci.c
M src/backend/utils/init/postinit.c
M src/include/storage/ipc.h
M src/include/storage/pg_shmem.h
Perform RLS subquery checks as the right user when going via a view.
commit : 2e606d0ad7984c15f323eacfc333990b93683cc7
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Tue, 2 Apr 2019 08:22:48 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Tue, 2 Apr 2019 08:22:48 +0100
When accessing a table with RLS via a view, the RLS checks are
performed as the view owner. However, the code neglected to propagate
that to any subqueries in the RLS checks. Fix that by calling
setRuleCheckAsUser() for all RLS policy quals and withCheckOption
checks for RTEs with RLS.
Back-patch to 9.5 where RLS was added.
Per bug #15708 from daurnimator.
Discussion: https://postgr.es/m/15708-d65cab2ce9b1717a@postgresql.org
M src/backend/rewrite/rowsecurity.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Update HINT for pre-existing shared memory block.
commit : 52e7e4d1dfe6e8f3b0923458cda732e8cb230719
author : Noah Misch <noah@leadboat.com>
date : Sun, 31 Mar 2019 19:32:48 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 31 Mar 2019 19:32:48 -0700
One should almost always terminate an old process, not use a manual
removal tool like ipcrm. Removal of the ipcclean script eleven years
ago (39627b1ae680cba44f6e56ca5facec4fdbfe9495) and its non-replacement
corroborate that manual shm removal is now a niche goal. Back-patch to
9.4 (all supported versions).
Reviewed by Daniel Gustafsson and Kyotaro HORIGUCHI.
Discussion: https://postgr.es/m/20180812064815.GB2301738@rfd.leadboat.com
M src/backend/utils/init/miscinit.c
Have pg_upgrade's Makefile honor NO_TEMP_INSTALL
commit : 7582251c1056ec657b9d32f547b8f661c6375e78
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 31 Mar 2019 08:08:14 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 31 Mar 2019 08:08:14 -0400
Backpatch to 9.5, when pg_upgrade's location changed.
Discussion: https://postgr.es/m/5506b8fa-7dad-8483-053c-7ca7ef04f01a@2ndQuadrant.com
M src/bin/pg_upgrade/Makefile
Track unowned relations in doubly-linked list
commit : 261aa218c9a0fcd93f6a27ca014c9d1ee278fa8b
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 27 Mar 2019 02:39:39 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 27 Mar 2019 02:39:39 +0100
Relations dropped in a single transaction are tracked in a list of
unowned relations. With large number of dropped relations this resulted
in poor performance at the end of a transaction, when the relations are
removed from the singly linked list one by one.
Commit b4166911 attempted to address this issue (particularly when it
happens during recovery) by removing the relations in a reverse order,
resulting in O(1) lookups in the list of unowned relations. This did
not work reliably, though, and it was possible to trigger the O(N^2)
behavior in various ways.
Instead of trying to remove the relations in a specific order with
respect to the linked list, which seems rather fragile, switch to a
regular doubly linked. That allows us to remove relations cheaply no
matter where in the list they are.
As b4166911 was a bugfix, backpatched to all supported versions, do the
same thing here.
Reviewed-by: Alvaro Herrera
Discussion: https://www.postgresql.org/message-id/flat/80c27103-99e4-1d0c-642c-d9f3b94aaa0a%402ndquadrant.com
Backpatch-through: 9.4
M src/backend/storage/smgr/md.c
M src/backend/storage/smgr/smgr.c
M src/include/storage/smgr.h
Doc: clarify that REASSIGN OWNED doesn't handle default privileges.
commit : 374fb6c0f9dad1048a2ef1ef814a27e01c8887d7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Mar 2019 17:18:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Mar 2019 17:18:06 -0400
It doesn't touch regular privileges either, but only the latter was
explicitly stated.
Discussion: https://postgr.es/m/155348282848.9808.12629518043813943231@wrigleys.postgresql.org
M doc/src/sgml/ref/drop_owned.sgml
M doc/src/sgml/ref/reassign_owned.sgml
Avoid double-free in vacuumlo error path.
commit : 171baf18325e30997123e9d5cf3e1a81e3a3f484
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Mar 2019 15:13:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Mar 2019 15:13:21 -0400
The code would do "PQclear(res)" twice if lo_unlink failed, evidently
due to careless thinking about how far out a "break" would break.
Remove the extra PQclear and adjust the loop logic so that we'll fall
out of both levels of loop after an error, as was clearly the intent.
Spotted by Coverity. I have no idea why it took this long to notice,
since the bug has been there since commit 67ccbb080. Accordingly,
back-patch to all supported branches.
M contrib/vacuumlo/vacuumlo.c
Fix WAL format incompatibility introduced by backpatching of 52ac6cd2d0
commit : cda5f6575306e50136a5f8ce3f76d9b2d772b738
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 24 Mar 2019 15:26:45 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 24 Mar 2019 15:26:45 +0300
52ac6cd2d0 added new field to ginxlogDeletePage and was backpatched to 9.4.
That led to problems when patched postgres instance applies WAL records
generated by non-patched one. WAL records generated by non-patched instance
don't contain new field, which patched one is expecting to see.
Thankfully, we can distinguish patched and non-patched WAL records by their data
size. If we see that WAL record is generated by non-patched instance, we skip
processing of new field. This commit comes with some assertions. In
particular, if it appears that on some platform struct data size didn't change
then static assertion will trigger.
Reported-by: Simon Riggs
Discussion: https://postgr.es/m/CANP8%2Bj%2BK4whxf7ET7%2BgO%2BG-baC3-WxqqH%3DnV4X2CgfEPA3Yu3g%40mail.gmail.com
Author: Alexander Korotkov
Reviewed-by: Simon Riggs, Alvaro Herrera
Backpatch-through: 9.4
M src/backend/access/gin/ginxlog.c
M src/include/access/gin_private.h
Remove inadequate check for duplicate "xml" PI.
commit : 06c320c8af6adce28a6634faaf46e320085ebfcd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 17:40:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 17:40:19 -0400
I failed to think about PIs starting with "xml". We don't really
need this check at all, so just take it out. Oversight in
commit 8d1dadb25 et al.
M src/backend/utils/adt/xml.c
Revert strlen -> strnlen optimization pre-v11.
commit : 809cccc3547462cd6b9a110ac82a5a60b9ee8587
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 17:35:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 17:35:05 -0400
We don't have a src/port substitute for that function in older branches,
so it fails on platforms lacking the function natively. Per buildfarm.
M src/backend/utils/adt/xml.c
Ensure xmloption = content while restoring pg_dump output.
commit : 08d8cfe3cfd69bff1729ba0cc2726e37b9c6eecf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 16:51:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 16:51:26 -0400
In combination with the previous commit, this ensures that valid XML
data can always be dumped and reloaded, whether it is "document"
or "content".
Discussion: https://postgr.es/m/CAN-V+g-6JqUQEQZ55Q3toXEN6d5Ez5uvzL4VR+8KtvJKj31taw@mail.gmail.com
M src/bin/pg_dump/pg_backup_archiver.c
Accept XML documents when xmloption = content, as required by SQL:2006+.
commit : da45927cef781b5fcdc89b9b1b96c3fb1d83bbd3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 16:24:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 16:24:30 -0400
Previously we were using the SQL:2003 definition, which doesn't allow
this, but that creates a serious dump/restore gotcha: there is no
setting of xmloption that will allow all valid XML data. Hence,
switch to the 2006 definition.
Since libxml doesn't accept <!DOCTYPE> directives in the mode we
use for CONTENT parsing, the implementation is to detect <!DOCTYPE>
in the input and switch to DOCUMENT parsing mode. This should not
cost much, because <!DOCTYPE> should be close to the front of the
input if it's there at all. It's possible that this causes the
error messages for malformed input to be slightly different than
they were before, if said input includes <!DOCTYPE>; but that does
not seem like a big problem.
In passing, buy back a few cycles in parsing of large XML documents
by not doing strlen() of the whole input in parse_xml_decl().
Back-patch because dump/restore failures are not nice. This change
shouldn't break any cases that worked before, so it seems safe to
back-patch.
Chapman Flack (revised a bit by me)
Discussion: https://postgr.es/m/CAN-V+g-6JqUQEQZ55Q3toXEN6d5Ez5uvzL4VR+8KtvJKj31taw@mail.gmail.com
M doc/src/sgml/datatype.sgml
M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_1.out
M src/test/regress/expected/xml_2.out
M src/test/regress/sql/xml.sql
Make checkpoint requests more robust.
commit : 4ae9c4bbb03d0cbc4c8bc7ba01b53f388608c2e6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Mar 2019 12:49:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Mar 2019 12:49:27 -0400
Commit 6f6a6d8b1 introduced a delay of up to 2 seconds if we're trying
to request a checkpoint but the checkpointer hasn't started yet (or,
much less likely, our kill() call fails). However buildfarm experience
shows that that's not quite enough for slow or heavily-loaded machines.
There's no good reason to assume that the checkpointer won't start
eventually, so we may as well make the timeout much longer, say 60 sec.
However, if the caller didn't say CHECKPOINT_WAIT, it seems like a bad
idea to be waiting at all, much less for as long as 60 sec. We can
remove the need for that, and make this whole thing more robust, by
adjusting the code so that the existence of a pending checkpoint
request is clear from the contents of shared memory, and making sure
that the checkpointer process will notice it at startup even if it did
not get a signal. In this way there's no need for a non-CHECKPOINT_WAIT
call to wait at all; if it can't send the signal, it can nonetheless
assume that the checkpointer will eventually service the request.
A potential downside of this change is that "kill -INT" on the checkpointer
process is no longer enough to trigger a checkpoint, should anyone be
relying on something so hacky. But there's no obvious reason to do it
like that rather than issuing a plain old CHECKPOINT command, so we'll
assume that nobody is. There doesn't seem to be a way to preserve this
undocumented quasi-feature without introducing race conditions.
Since a principal reason for messing with this is to prevent intermittent
buildfarm failures, back-patch to all supported branches.
Discussion: https://postgr.es/m/27830.1552752475@sss.pgh.pa.us
M src/backend/postmaster/checkpointer.c
M src/include/access/xlog.h
Fix volatile vs. pointer confusion
commit : 361cabb11d36afaf466d76e1bda1778501137dcf
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 08:25:25 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 08:25:25 +0100
Variables used after a longjmp() need to be declared volatile. In
case of a pointer, it's the pointer itself that needs to be declared
volatile, not the pointed-to value. So we need
PyObject *volatile items;
instead of
volatile PyObject *items; /* wrong */
Discussion: https://www.postgresql.org/message-id/flat/f747368d-9e1a-c46a-ac76-3c27da32e8e4%402ndquadrant.com
M contrib/hstore_plpython/hstore_plpython.c
Ensure dummy paths have correct required_outer if rel is parameterized.
commit : 71288846efc89dc2fdfbb08e2807340ed6f8cd45
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Mar 2019 12:16:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Mar 2019 12:16:10 -0400
The assertions added by commits 34ea1ab7f et al found another problem:
set_dummy_rel_pathlist and mark_dummy_rel were failing to label
the dummy paths they create with the correct outer_relids, in case
the relation is necessarily parameterized due to having lateral
references in its tlist. It's likely that this has no user-visible
consequences in production builds, at the moment; but still an assertion
failure is a bad thing, so back-patch the fix.
Per bug #15694 from Roman Zharkov (via Alexander Lakhin)
and an independent report by Tushar Ahuja.
Discussion: https://postgr.es/m/15694-74f2ca97e7044f7f@postgresql.org
Discussion: https://postgr.es/m/7d72ab20-c725-3ce2-f99d-4e64dd8a0de6@enterprisedb.com
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/path/joinrels.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix potential memory access violation in ecpg if filename of include file is shorter than 2 characters.
commit : 72f725ab25bdf4ad12c9586521935eb9307fcfe1
author : Michael Meskes <meskes@postgresql.org>
date : Mon, 11 Mar 2019 16:11:16 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Mon, 11 Mar 2019 16:11:16 +0100
Patch by: "Wu, Fei" <wufei.fnst@cn.fujitsu.com>
M src/interfaces/ecpg/preproc/pgc.l
Disallow NaN as a value for floating-point GUCs.
commit : d8f8183c04671b0ffe26ae6f8aee9e50df5fff1e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Mar 2019 12:58:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Mar 2019 12:58:52 -0400
None of the code that uses GUC values is really prepared for them to
hold NaN, but parse_real() didn't have any defense against accepting
such a value. Treat it the same as a syntax error.
I haven't attempted to analyze the exact consequences of setting any
of the float GUCs to NaN, but since they're quite unlikely to be good,
this seems like a back-patchable bug fix.
Note: we don't need an explicit test for +-Infinity because those will
be rejected by existing range checks. I added a regression test for
that in HEAD, but not older branches because the spelling of the value
in the error message will be platform-dependent in branches where we
don't always use port/snprintf.c.
Discussion: https://postgr.es/m/1798.1552165479@sss.pgh.pa.us
M src/backend/utils/misc/guc.c
M src/test/regress/expected/guc.out
M src/test/regress/sql/guc.sql
Simplify release-note links to back branches.
commit : a2c59a28c738959e9a5e7d8e95140ff89787a95c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 9 Mar 2019 18:42:19 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 9 Mar 2019 18:42:19 -0500
Now that https://www.postgresql.org/docs/release/ is populated,
replace the stopgap text we had under "Prior Releases" with
a pointer to that archive.
Discussion: https://postgr.es/m/e0f09c9a-bd2b-862a-d379-601dfabc8969@postgresql.org
M doc/src/sgml/release.sgml
Fix error handling of readdir() port implementation on first file lookup
commit : 977f833772de09970da375fb68a46e33bbf397cb
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 4 Mar 2019 09:50:19 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 4 Mar 2019 09:50:19 +0900
The implementation of readdir() in src/port/ which gets used by MSVC has
been added in 399a36a, and since the beginning it considers all errors
on the first file lookup as ENOENT, setting errno accordingly and
letting the routine caller think that the directory is empty. While
this is normally enough for the case of the backend, this can confuse
callers of this routine on Windows as all errors would map to the same
behavior. So, for example, even permission errors would be thought as
having an empty directory, while there could be contents in it.
This commit changes the error handling so as readdir() gets a behavior
similar to native implementations: force errno=0 when seeing
ERROR_FILE_NOT_FOUND as error and consider other errors as plain
failures.
While looking at the patch, I noticed that MinGW does not enforce
errno=0 when looking at the first file, but it gets enforced on the next
file lookups. A comment related to that was incorrect in the code.
Reported-by: Yuri Kurenkov
Diagnosed-by: Yuri Kurenkov, Grigory Smolkin
Author: Konstantin Knizhnik
Reviewed-by: Andrew Dunstan, Michael Paquier
Discussion: https://postgr.es/m/2cad7829-8d66-e39c-b937-ac825db5203d@postgrespro.ru
Backpatch-through: 9.4
M src/port/dirent.c
Further fixing for multi-row VALUES lists for updatable views.
commit : 556fdd49c9e003d96b28c987d533dcd4238d0cd4
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sun, 3 Mar 2019 10:57:37 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sun, 3 Mar 2019 10:57:37 +0000
Previously, rewriteTargetListIU() generated a list of attribute
numbers from the targetlist, which were passed to rewriteValuesRTE(),
which expected them to contain the same number of entries as there are
columns in the VALUES RTE, and to be in the same order. That was fine
when the target relation was a table, but for an updatable view it
could be broken in at least three different ways ---
rewriteTargetListIU() could insert additional targetlist entries for
view columns with defaults, the view columns could be in a different
order from the columns of the underlying base relation, and targetlist
entries could be merged together when assigning to elements of an
array or composite type. As a result, when recursing to the base
relation, the list of attribute numbers generated from the rewritten
targetlist could no longer be relied upon to match the columns of the
VALUES RTE. We got away with that prior to 41531e42d3 because it used
to always be the case that rewriteValuesRTE() did nothing for the
underlying base relation, since all DEFAULTS had already been replaced
when it was initially invoked for the view, but that was incorrect
because it failed to apply defaults from the base relation.
Fix this by examining the targetlist entries more carefully and
picking out just those that are simple Vars referencing the VALUES
RTE. That's sufficient for the purposes of rewriteValuesRTE(), which
is only responsible for dealing with DEFAULT items in the VALUES
RTE. Any DEFAULT item in the VALUES RTE that doesn't have a matching
simple-Var-assignment in the targetlist is an error which we complain
about, but in theory that ought to be impossible.
Additionally, move this code into rewriteValuesRTE() to give a clearer
separation of concerns between the 2 functions. There is no need for
rewriteTargetListIU() to know about the details of the VALUES RTE.
While at it, fix the comment for rewriteValuesRTE() which claimed that
it doesn't support array element and field assignments --- that hasn't
been true since a3c7a993d5 (9.6 and later).
Back-patch to all supported versions, with minor differences for the
pre-9.6 branches, which don't support array element and field
assignments to the same column in multi-row VALUES lists.
Reviewed by Amit Langote.
Discussion: https://postgr.es/m/15623-5d67a46788ec8b7f@postgresql.org
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Improve documentation of data_sync_retry
commit : 1e5ed16c618a2f62e7a42c303ad62575423c7f31
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 28 Feb 2019 11:02:36 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 28 Feb 2019 11:02:36 +0900
Reflecting an updated parameter value requires a server restart, which
was not mentioned in the documentation and in postgresql.conf.sample.
Reported-by: Thomas Poty
Discussion: https://postgr.es/m/15659-0cd812f13027a2d8@postgresql.org
M doc/src/sgml/config.sgml
M src/backend/utils/misc/postgresql.conf.sample
Fix ecpg bugs caused by missing semicolons in the backend grammar.
commit : 3a682a21b7f9fcd996e282cd7c6d778e9a7febc2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Feb 2019 12:51:51 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Feb 2019 12:51:51 -0500
The Bison documentation clearly states that a semicolon is required
after every grammar rule, and our scripts that generate ecpg's
grammar from the backend's implicitly assumed this is true. But it
turns out that only ancient versions of Bison actually enforce that.
There have been a couple of rules without trailing semicolons in
gram.y for some time, and as a consequence, ecpg's grammar was faulty
and produced wrong output for the affected statements.
To fix, add the missing semis, and add some cross-checks to ecpg's
scripts so that they'll bleat if we mess this up again.
The cases that were broken were:
* "SET variable = DEFAULT" (but not "SET variable TO DEFAULT"),
as well as allied syntaxes such as ALTER SYSTEM SET ... DEFAULT.
These produced syntactically invalid output that the server
would reject.
* Multiple type names in DROP TYPE/DOMAIN commands. Only the
first type name would be listed in the emitted command.
Per report from Daisuke Higuchi. Back-patch to all supported versions.
Discussion: https://postgr.es/m/1803D792815FC24D871C00D17AE95905DB51CE@g01jpexmbkw24
M src/backend/parser/gram.y
M src/interfaces/ecpg/preproc/check_rules.pl
M src/interfaces/ecpg/preproc/parse.pl
Tolerate EINVAL when calling fsync() on a directory.
commit : 0ec89a0f6752d55efee4377928087b1865d7ac5e
author : Thomas Munro <tmunro@postgresql.org>
date : Sun, 24 Feb 2019 23:59:26 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Sun, 24 Feb 2019 23:59:26 +1300
Previously, we tolerated EBADF as a way for the operating system to
indicate that it doesn't support fsync() on a directory. Tolerate
EINVAL too, for older versions of Linux CIFS.
Bug #15636. Back-patch all the way.
Reported-by: John Klann
Discussion: https://postgr.es/m/15636-d380890dafd78fc6@postgresql.org
M src/backend/storage/file/fd.c
M src/bin/initdb/initdb.c
Fix plan created for inherited UPDATE/DELETE with all tables excluded.
commit : 0fe3f6dd45c95f82bf6dcd98b4f9e029ce433ce0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Feb 2019 12:23:00 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Feb 2019 12:23:00 -0500
In the case where inheritance_planner() finds that every table has
been excluded by constraints, it thought it could get away with
making a plan consisting of just a dummy Result node. While certainly
there's no updating or deleting to be done, this had two user-visible
problems: the plan did not report the correct set of output columns
when a RETURNING clause was present, and if there were any
statement-level triggers that should be fired, it didn't fire them.
Hence, rather than only generating the dummy Result, we need to
stick a valid ModifyTable node on top, which requires a tad more
effort here.
It's been broken this way for as long as inheritance_planner() has
known about deleting excluded subplans at all (cf commit 635d42e9c),
so back-patch to all supported branches.
Amit Langote and Tom Lane, per a report from Petr Fedorov.
Discussion: https://postgr.es/m/5da6f0f0-1364-1876-6978-907678f89a3e@phystech.edu
M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/inherit.out
M src/test/regress/expected/triggers.out
M src/test/regress/sql/inherit.sql
M src/test/regress/sql/triggers.sql
Make object address handling more robust
commit : 545928bbbf9c8c2bfa748702d40a43d6a560216b
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 20 Feb 2019 09:12:02 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 20 Feb 2019 09:12:02 -0300
pg_identify_object_as_address crashes when passed certain tuples from
inconsistent system catalogs. Make it more defensive.
Author: Álvaro Herrera
Reviewed-by: Michaël Paquier
Discussion: https://postgr.es/m/20190218202743.GA12392@alvherre.pgsql
M src/backend/catalog/objectaddress.c
Fix DEFAULT-handling in multi-row VALUES lists for updatable views.
commit : 90f91bfbd76f1ce0e4692f7c17813f5f226050f2
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 20 Feb 2019 08:22:52 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 20 Feb 2019 08:22:52 +0000
INSERT ... VALUES for a single VALUES row is implemented differently
from a multi-row VALUES list, which causes inconsistent behaviour in
the way that DEFAULT items are handled. In particular, when inserting
into an auto-updatable view on top of a table with a column default, a
DEFAULT item in a single VALUES row gets correctly replaced with the
table column's default, but for a multi-row VALUES list it is replaced
with NULL.
Fix this by allowing rewriteValuesRTE() to leave DEFAULT items in the
VALUES list untouched if the target relation is an auto-updatable view
and has no column default, deferring DEFAULT-expansion until the query
against the base relation is rewritten. For all other types of target
relation, including tables and trigger- and rule-updatable views, we
must continue to replace DEFAULT items with NULL in the absence of a
column default.
This is somewhat complicated by the fact that if an auto-updatable
view has DO ALSO rules attached, the VALUES lists for the product
queries need to be handled differently from the original query, since
the product queries need to act like rule-updatable views whereas the
original query has auto-updatable view semantics.
Back-patch to all supported versions.
Reported by Roger Curley (bug #15623). Patch by Amit Langote and me.
Discussion: https://postgr.es/m/15623-5d67a46788ec8b7f@postgresql.org
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Mark correctly initial slot snapshots with MVCC type when built
commit : 03cd99a8e802e054aac53e4544613b207803f4a0
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 20 Feb 2019 12:32:15 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 20 Feb 2019 12:32:15 +0900
When building an initial slot snapshot, snapshots are marked with
historic MVCC snapshots as type with the marker field being set in
SnapBuildBuildSnapshot() but not overriden in SnapBuildExportSnapshot().
Existing callers of SnapBuildBuildSnapshot() do not care about the type
of snapshot used, but extensions calling it actually may, as reported.
Author: Antonin Houska
Reviewed-by: Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/23215.1527665193@localhost
Backpatch-through: 9.4
M src/backend/replication/logical/snapbuild.c
Fix omissions in ecpg/test/sql/.gitignore.
commit : e5e4ad114b7dfebbe9959a1b2fc0035458a4a722
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Feb 2019 21:24:38 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Feb 2019 21:24:38 -0500
Oversights in commits 050710b36 and e81f0e311.
M src/interfaces/ecpg/test/sql/.gitignore
Sync ECPG's CREATE TABLE AS statement with backend's.
commit : 180606b6851edd447bde566fea24e67557ae016f
author : Michael Meskes <meskes@postgresql.org>
date : Mon, 18 Feb 2019 11:57:34 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Mon, 18 Feb 2019 11:57:34 +0100
Author: Higuchi-san ("Higuchi, Daisuke" <higuchi.daisuke@jp.fujitsu.com>)
M src/interfaces/ecpg/preproc/ecpg.trailer
M src/interfaces/ecpg/test/ecpg_schedule
A src/interfaces/ecpg/test/expected/sql-createtableas.c
A src/interfaces/ecpg/test/expected/sql-createtableas.stderr
A src/interfaces/ecpg/test/expected/sql-createtableas.stdout
M src/interfaces/ecpg/test/sql/Makefile
A src/interfaces/ecpg/test/sql/createtableas.pgc
Fix documentation for dblink_error_message() return value
commit : 916b50a5ae0a7a64ca3b2497ccb1b97ce72f8aa9
author : Joe Conway <mail@joeconway.com>
date : Sun, 17 Feb 2019 13:14:39 -0500
committer: Joe Conway <mail@joeconway.com>
date : Sun, 17 Feb 2019 13:14:39 -0500
The dblink documentation claims that an empty string is returned if there
has been no error, however OK is actually returned in that case. Also,
clarify that an async error may not be seen unless dblink_is_busy() or
dblink_get_result() have been called first.
Backpatch to all supported branches.
Reported-by: realyota
Backpatch-through: 9.4
Discussion: https://postgr.es/m/153371978486.1298.2091761143788088262@wrigleys.postgresql.org
M doc/src/sgml/dblink.sgml
Fix CREATE VIEW to allow zero-column views.
commit : 0b476cf623dd5849679d4509f6b06b8be7f3436e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Feb 2019 12:37:32 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Feb 2019 12:37:32 -0500
We should logically have allowed this case when we allowed zero-column
tables, but it was overlooked.
Although this might be thought a feature addition, it's really a bug
fix, because it was possible to create a zero-column view via
the convert-table-to-view code path, and then you'd have a situation
where dump/reload would fail. Hence, back-patch to all supported
branches.
Arrange the added test cases to provide coverage of the related
pg_dump code paths (since these views will be dumped and reloaded
during the pg_upgrade regression test). I also made them test
the case where pg_dump has to postpone the view rule into post-data,
which disturbingly had no regression coverage before.
Report and patch by Ashutosh Sharma (test case by me)
Discussion: https://postgr.es/m/CAE9k0PkmHdeSaeZt2ujnb_cKucmK3sDDceDzw7+d5UZoNJPYOg@mail.gmail.com
M src/backend/commands/view.c
M src/test/regress/expected/create_view.out
M src/test/regress/expected/rules.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/sql/create_view.sql
Doc: remove ancient comment.
commit : 71c8ea4b68949185f9d18396237587b5f91369af
author : Tatsuo Ishii <ishii@postgresql.org>
date : Sun, 17 Feb 2019 20:42:58 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Sun, 17 Feb 2019 20:42:58 +0900
There's a very old comment in rules.sgml added back to 2003. It
expected to a feature coming back but it never happened. So now we can
safely remove the comment. Back-patched to all supported branches.
Discussion: https://postgr.es/m/20190211.191004.219630835457494660.t-ishii%40sraoss.co.jp
M doc/src/sgml/rules.sgml
Fix support for CREATE TABLE IF NOT EXISTS AS EXECUTE
commit : 06cdab9df413238c24f839f8806164c36b75f0e5
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 15 Feb 2019 17:12:51 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 15 Feb 2019 17:12:51 +0900
The grammar IF NOT EXISTS for CTAS is supported since 9.5 and documented
as such, however the case of using EXECUTE as query has never been
covered as EXECUTE CTAS statements and normal CTAS statements are parsed
separately.
Author: Andreas Karlsson
Discussion: https://postgr.es/m/2ddcc188-e37c-a0be-32bf-a56b07c3559e@proxel.se
Backpatch-through: 9.5
M src/backend/parser/gram.y
M src/test/regress/expected/create_table.out
M src/test/regress/sql/create_table.sql
Fix race in dsm_attach() when handles are reused.
commit : b7c8766d34803b5ad7d371625aa994f4648f7845
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 15 Feb 2019 10:19:11 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 15 Feb 2019 10:19:11 +1300
DSM handle values can be reused as soon as the underlying shared memory
object has been destroyed. That means that for a brief moment we
might have two DSM slots with the same handle. While trying to attach,
if we encounter a slot with refcnt == 1, meaning that it is currently
being destroyed, we should continue our search in case the same handle
exists in another slot.
The race manifested as a rare "dsa_area could not attach to segment"
error, and was more likely in 10 and 11 due to the lack of distinct
seed for random() in parallel workers. It was made very unlikely in
in master by commit 197e4af9, and older releases don't usually create
new DSM segments in background workers so it was also unlikely there.
This fixes the root cause of bug report #15585, in which the error
could also sometimes result in a self-deadlock in the error path.
It's not yet clear if further changes are needed to avoid that failure
mode.
Back-patch to 9.4, where dsm.c arrived.
Author: Thomas Munro
Reported-by: Justin Pryzby, Sergei Kornilov
Discussion: https://postgr.es/m/20190207014719.GJ29720@telsasoft.com
Discussion: https://postgr.es/m/15585-324ff6a93a18da46@postgresql.org
M src/backend/storage/ipc/dsm.c
Relax overly strict assertion
commit : 45ed482f1a899dbf5b0db13686d817718ae8cf97
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 12 Feb 2019 18:42:37 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 12 Feb 2019 18:42:37 -0300
Ever since its birth, ReorderBufferBuildTupleCidHash() has contained an
assertion that a catalog tuple cannot change Cmax after acquiring one. But
that's wrong: if a subtransaction executes DDL that affects that catalog
tuple, and later aborts and another DDL affects the same tuple, it will
change Cmax. Relax the assertion to merely verify that the Cmax remains
valid and monotonically increasing, instead.
Add a test that tickles the relevant code.
Diagnosed by, and initial patch submitted by: Arseny Sher
Co-authored-by: Arseny Sher
Discussion: https://postgr.es/m/874l9p8hyw.fsf@ars-thinkpad
M contrib/test_decoding/expected/ddl.out
M contrib/test_decoding/sql/ddl.sql
M src/backend/replication/logical/reorderbuffer.c
Fix erroneous error reports in snapbuild.c.
commit : 442d44fb480d1298a3ed47f869ad2c7fbfca53a7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Feb 2019 01:12:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Feb 2019 01:12:52 -0500
It's pretty unhelpful to report the wrong file name in a complaint
about syscall failure, but SnapBuildSerialize managed to do that twice
in a span of 50 lines. Also fix half a dozen missing or poorly-chosen
errcode assignments; that's mostly cosmetic, but still wrong.
Noted while studying recent failures on buildfarm member nightjar.
I'm not sure whether those reports are actually giving the wrong
filename, because there are two places here with identically
spelled error messages. The other one is specifically coded not
to report ENOENT, but if it's this one, how could we be getting
ENOENT from open() with O_CREAT? Need to sit back and await results.
However, these ereports are clearly broken from birth, so back-patch.
M src/backend/replication/logical/snapbuild.c