Last-minute updates for release notes.
commit : bd9c6dc9ab9de8f07647015af65d6d2cec0057e3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 May 2015 18:33:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 May 2015 18:33:58 -0400
Revise description of CVE-2015-3166, in line with scaled-back patch.
Change release date.
Security: CVE-2015-3166
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
Revert error-throwing wrappers for the printf family of functions.
commit : 2eb2fcd56b76ff7aef03f7de772e7459997e61ad
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 May 2015 18:16:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 May 2015 18:16:19 -0400
This reverts commit 16304a013432931e61e623c8d85e9fe24709d9ba, except
for its changes in src/port/snprintf.c; as well as commit
cac18a76bb6b08f1ecc2a85e46c9d2ab82dd9d23 which is no longer needed.
Fujii Masao reported that the previous commit caused failures in psql on
OS X, since if one exits the pager program early while viewing a query
result, psql sees an EPIPE error from fprintf --- and the wrapper function
thought that was reason to panic. (It's a bit surprising that the same
does not happen on Linux.) Further discussion among the security list
concluded that the risk of other such failures was far too great, and
that the one-size-fits-all approach to error handling embodied in the
previous patch is unlikely to be workable.
This leaves us again exposed to the possibility of the type of failure
envisioned in CVE-2015-3166. However, that failure mode is strictly
hypothetical at this point: there is no concrete reason to believe that
an attacker could trigger information disclosure through the supposed
mechanism. In the first place, the attack surface is fairly limited,
since so much of what the backend does with format strings goes through
stringinfo.c or psprintf(), and those already had adequate defenses.
In the second place, even granting that an unprivileged attacker could
control the occurrence of ENOMEM with some precision, it's a stretch to
believe that he could induce it just where the target buffer contains some
valuable information. So we concluded that the risk of non-hypothetical
problems induced by the patch greatly outweighs the security risks.
We will therefore revert, and instead undertake closer analysis to
identify specific calls that may need hardening, rather than attempt a
universal solution.
We have kept the portion of the previous patch that improved snprintf.c's
handling of errors when it calls the platform's sprintf(). That seems to
be an unalloyed improvement.
Security: CVE-2015-3166
M src/include/port.h
M src/interfaces/ecpg/compatlib/Makefile
M src/interfaces/ecpg/ecpglib/.gitignore
M src/interfaces/ecpg/ecpglib/Makefile
M src/interfaces/ecpg/pgtypeslib/.gitignore
M src/interfaces/ecpg/pgtypeslib/Makefile
M src/interfaces/libpq/.gitignore
M src/interfaces/libpq/Makefile
M src/interfaces/libpq/bcc32.mak
M src/interfaces/libpq/win32.mak
M src/pl/plperl/plperl.h
M src/pl/plpython/plpython.h
M src/port/Makefile
M src/port/snprintf.c
D src/port/syswrap.c
M src/tools/msvc/Mkvcbuild.pm
Fix off-by-one error in Assertion.
commit : ada84478d89a49e305b79022a8ee0d2f12bcfc5f
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 19 May 2015 19:21:46 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 19 May 2015 19:21:46 +0300
The point of the assertion is to ensure that the arrays allocated in stack
are large enough, but the check was one item short.
This won't matter in practice because MaxIndexTuplesPerPage is an
overestimate, so you can't have that many items on a page in reality.
But let's be tidy.
Spotted by Anastasia Lubennikova. Backpatch to all supported versions, like
the patch that added the assertion.
M src/backend/storage/page/bufpage.c
Stamp 9.4.2.
commit : 7aeba23ee2cab86c78a80e3face3ca62ca87b5d7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 May 2015 14:29:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 May 2015 14:29:04 -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
Fix error message in pre_sync_fname.
commit : 20affd62e22d5bbf2d945dd25920d1aa54844933
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 18 May 2015 12:53:09 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 18 May 2015 12:53:09 -0400
The old one didn't include %m anywhere, and required extra
translation.
Report by Peter Eisentraut. Fix by me. Review by Tom Lane.
M src/backend/storage/file/fd.c
Last-minute updates for release notes.
commit : dd5015ad1ac0d80c3bb656042b46aaf5bca2f0b2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 May 2015 12:09:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 May 2015 12:09:02 -0400
Add entries for security issues.
Security: CVE-2015-3165 through CVE-2015-3167
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
pgcrypto: Report errant decryption as "Wrong key or corrupt data".
commit : fba1fb4efba51587cd0a9817af1f3e629caf157a
author : Noah Misch <noah@leadboat.com>
date : Mon, 18 May 2015 10:02:31 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 18 May 2015 10:02:31 -0400
This has been the predominant outcome. When the output of decrypting
with a wrong key coincidentally resembled an OpenPGP packet header,
pgcrypto could instead report "Corrupt data", "Not text data" or
"Unsupported compression algorithm". The distinct "Corrupt data"
message added no value. The latter two error messages misled when the
decrypted payload also exhibited fundamental integrity problems. Worse,
error message variance in other systems has enabled cryptologic attacks;
see RFC 4880 section "14. Security Considerations". Whether these
pgcrypto behaviors are likewise exploitable is unknown.
In passing, document that pgcrypto does not resist side-channel attacks.
Back-patch to 9.0 (all supported versions).
Security: CVE-2015-3167
M contrib/pgcrypto/expected/pgp-decrypt.out
M contrib/pgcrypto/expected/pgp-pubkey-decrypt.out
M contrib/pgcrypto/mbuf.c
M contrib/pgcrypto/pgp-decrypt.c
M contrib/pgcrypto/pgp.h
M contrib/pgcrypto/px.c
M contrib/pgcrypto/px.h
M contrib/pgcrypto/sql/pgp-decrypt.sql
M doc/src/sgml/pgcrypto.sgml
Check return values of sensitive system library calls.
commit : ca325941d54b537e7921dbe6615bae083651dffd
author : Noah Misch <noah@leadboat.com>
date : Mon, 18 May 2015 10:02:31 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 18 May 2015 10:02:31 -0400
PostgreSQL already checked the vast majority of these, missing this
handful that nearly cannot fail. If putenv() failed with ENOMEM in
pg_GSS_recvauth(), authentication would proceed with the wrong keytab
file. If strftime() returned zero in cache_locale_time(), using the
unspecified buffer contents could lead to information exposure or a
crash. Back-patch to 9.0 (all supported versions).
Other unchecked calls to these functions, especially those in frontend
code, pose negligible security concern. This patch does not address
them. Nonetheless, it is always better to check return values whose
specification provides for indicating an error.
In passing, fix an off-by-one error in strftime_win32()'s invocation of
WideCharToMultiByte(). Upon retrieving a value of exactly MAX_L10N_DATA
bytes, strftime_win32() would overrun the caller's buffer by one byte.
MAX_L10N_DATA is chosen to exceed the length of every possible value, so
the vulnerable scenario probably does not arise.
Security: CVE-2015-3166
M src/backend/libpq/auth.c
M src/backend/utils/adt/pg_locale.c
Add error-throwing wrappers for the printf family of functions.
commit : 2e3bd06654217adcf41878ba3517f31f0adf0ea6
author : Noah Misch <noah@leadboat.com>
date : Mon, 18 May 2015 10:02:31 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 18 May 2015 10:02:31 -0400
All known standard library implementations of these functions can fail
with ENOMEM. A caller neglecting to check for failure would experience
missing output, information exposure, or a crash. Check return values
within wrappers and code, currently just snprintf.c, that bypasses the
wrappers. The wrappers do not return after an error, so their callers
need not check. Back-patch to 9.0 (all supported versions).
Popular free software standard library implementations do take pains to
bypass malloc() in simple cases, but they risk ENOMEM for floating point
numbers, positional arguments, large field widths, and large precisions.
No specification demands such caution, so this commit regards every call
to a printf family function as a potential threat.
Injecting the wrappers implicitly is a compromise between patch scope
and design goals. I would prefer to edit each call site to name a
wrapper explicitly. libpq and the ECPG libraries would, ideally, convey
errors to the caller rather than abort(). All that would be painfully
invasive for a back-patched security fix, hence this compromise.
Security: CVE-2015-3166
M src/include/port.h
M src/interfaces/ecpg/compatlib/Makefile
M src/interfaces/ecpg/ecpglib/.gitignore
M src/interfaces/ecpg/ecpglib/Makefile
M src/interfaces/ecpg/pgtypeslib/.gitignore
M src/interfaces/ecpg/pgtypeslib/Makefile
M src/interfaces/libpq/.gitignore
M src/interfaces/libpq/Makefile
M src/interfaces/libpq/bcc32.mak
M src/interfaces/libpq/win32.mak
M src/pl/plperl/plperl.h
M src/pl/plpython/plpython.h
M src/port/Makefile
M src/port/snprintf.c
A src/port/syswrap.c
M src/tools/msvc/Mkvcbuild.pm
Permit use of vsprintf() in PostgreSQL code.
commit : f7c4fe7d95a3f323df3b0dc3bffff5fa9d708a0c
author : Noah Misch <noah@leadboat.com>
date : Mon, 18 May 2015 10:02:31 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 18 May 2015 10:02:31 -0400
The next commit needs it. Back-patch to 9.0 (all supported versions).
M src/include/port.h
M src/port/snprintf.c
Prevent a double free by not reentering be_tls_close().
commit : 7a0d48ac7f5ad660414f1b0b6a36cb2b2b7a3667
author : Noah Misch <noah@leadboat.com>
date : Mon, 18 May 2015 10:02:31 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 18 May 2015 10:02:31 -0400
Reentering this function with the right timing caused a double free,
typically crashing the backend. By synchronizing a disconnection with
the authentication timeout, an unauthenticated attacker could achieve
this somewhat consistently. Call be_tls_close() solely from within
proc_exit_prepare(). Back-patch to 9.0 (all supported versions).
Benkocs Norbert Attila
Security: CVE-2015-3165
M src/backend/libpq/be-secure.c
M src/backend/libpq/pqcomm.c
M src/backend/postmaster/postmaster.c
Translation updates
commit : 05da36196f559b9fcf016fa6a70dfd33d6936a78
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 18 May 2015 08:38:34 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 18 May 2015 08:38:34 -0400
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: d5e6d568c213297ebd5530ad14fb26d75ed66c25
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/pt_BR.po
M src/backend/po/ru.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/pt_BR.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/pt_BR.po
M src/bin/pg_config/po/fr.po
M src/bin/pg_controldata/po/fr.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_resetxlog/po/de.po
M src/bin/pg_resetxlog/po/fr.po
M src/bin/pg_resetxlog/po/pt_BR.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/psql/po/de.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/pt_BR.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/pt_BR.po
M src/interfaces/ecpg/ecpglib/po/fr.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/pt_BR.po
M src/pl/plperl/po/fr.po
M src/pl/plpgsql/src/po/fr.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/pt_BR.po
M src/pl/tcl/po/fr.po
Fix typos
commit : 367b34a22c47241d35bfba8b4e644443cc00bdbd
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 17 May 2015 22:21:36 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 17 May 2015 22:21:36 -0400
M contrib/pg_upgrade/pg_upgrade.c
M src/bin/pg_resetxlog/pg_resetxlog.c
Release notes for 9.4.2, 9.3.7, 9.2.11, 9.1.16, 9.0.20.
commit : e427ea76409fd2202cd47ff80fee5904f6796358
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 May 2015 15:54:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 May 2015 15:54:20 -0400
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
Fix whitespace
commit : d817b7a4a3645d1df9d9091de4ef066fdaec73f6
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 16 May 2015 20:29:22 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 16 May 2015 20:29:22 -0400
M src/backend/access/transam/multixact.c
pg_upgrade: properly handle timeline variables
commit : 5f65396359e9e44c8f5eb5133cb50abba6326bb6
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 16 May 2015 15:16:28 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 16 May 2015 15:16:28 -0400
There is no behavior change here as we now always set the timeline to
one.
Report by Tom Lane
Backpatch to 9.3 and 9.4
M contrib/pg_upgrade/controldata.c
M contrib/pg_upgrade/pg_upgrade.h
Fix docs typo
commit : 73f074ca69a4440606fdb1d275a81991c511db31
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 May 2015 13:28:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 May 2015 13:28:26 -0400
I don't think "respectfully" is what was meant here ...
M doc/src/sgml/client-auth.sgml
pg_upgrade: force timeline 1 in the new cluster
commit : 387a3e46cfdddad2e07f0d1a47d8fcdba89351cd
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 16 May 2015 00:40:18 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 16 May 2015 00:40:18 -0400
Previously, this prevented promoted standby servers from being upgraded
because of a missing WAL history file. (Timeline 1 doesn't need a
history file, and we don't copy WAL files anyway.)
Report by Christian Echerer(?), Alexey Klyukin
Backpatch through 9.0
M contrib/pg_upgrade/pg_upgrade.c
pg_upgrade: only allow template0 to be non-connectable
commit : 31f5d3f3544f76892febccb4c2840ada9e765597
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 16 May 2015 00:10:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 16 May 2015 00:10:03 -0400
This patch causes pg_upgrade to error out during its check phase if:
(1) template0 is marked connectable
or
(2) any other database is marked non-connectable
This is done because, in the first case, pg_upgrade would fail because
the pg_dumpall --globals restore would fail, and in the second case, the
database would not be restored, leading to data loss.
Report by Matt Landry (1), Stephen Frost (2)
Backpatch through 9.0
M contrib/pg_upgrade/check.c
Update time zone data files to tzdata release 2015d.
commit : d0ddcf62e2b883222dc7046b6e05ed37f13d1802
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 May 2015 19:35:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 May 2015 19:35:29 -0400
DST law changes in Egypt, Mongolia, Palestine.
Historical corrections for Canada and Chile.
Revised zone abbreviation for America/Adak (HST/HDT not HAST/HADT).
M src/timezone/data/africa
M src/timezone/data/antarctica
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/backward
M src/timezone/data/backzone
M src/timezone/data/europe
M src/timezone/data/northamerica
M src/timezone/data/southamerica
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/America.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Pacific.txt
Docs: fix erroneous claim about max byte length of GB18030.
commit : f173fb8a6df82c6146a1ce812a8cdb4fdca9943d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 May 2015 14:59:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 May 2015 14:59:00 -0400
This encoding has characters up to 4 bytes long, not 2.
M doc/src/sgml/charset.sgml
Fix RBM_ZERO_AND_LOCK mode to not acquire lock on local buffers.
commit : 462a2f1f019fa16087fe2f59e96e339a703923b2
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 13 May 2015 09:44:43 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 13 May 2015 09:44:43 +0300
Commit 81c45081 introduced a new RBM_ZERO_AND_LOCK mode to ReadBuffer, which
takes a lock on the buffer before zeroing it. However, you cannot take a
lock on a local buffer, and you got a segfault instead. The version of that
patch committed to master included a check for !isLocalBuf, and therefore
didn't crash, but oddly I missed that in the back-patched versions. This
patch adds that check to the back-branches too.
RBM_ZERO_AND_LOCK mode is only used during WAL replay, and in hash indexes.
WAL replay only deals with shared buffers, so the only way to trigger the
bug is with a temporary hash index.
Reported by Artem Ignatyev, analysis by Tom Lane.
M src/backend/storage/buffer/bufmgr.c
Fix incorrect checking of deferred exclusion constraint after a HOT update.
commit : 4d3d9719d28ff9956540c36a05a4846b55b0234b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 May 2015 12:25:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 May 2015 12:25:28 -0400
If a row that potentially violates a deferred exclusion constraint is
HOT-updated later in the same transaction, the exclusion constraint would
be reported as violated when the check finally occurs, even if the row(s)
the new row originally conflicted with have since been removed. This
happened because the wrong TID was passed to check_exclusion_constraint(),
causing the live HOT-updated row to be seen as a conflicting row rather
than recognized as the row-under-test.
Per bug #13148 from Evan Martin. It's been broken since exclusion
constraints were invented, so back-patch to all supported branches.
M src/backend/commands/constraint.c
M src/test/regress/input/constraints.source
M src/test/regress/output/constraints.source
Increase threshold for multixact member emergency autovac to 50%.
commit : ea70595a3b0ff58bbd9a613fb9458ff6583cbb12
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 11 May 2015 12:07:13 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 11 May 2015 12:07:13 -0400
Analysis by Noah Misch shows that the 25% threshold set by commit
53bb309d2d5a9432d2602c93ed18e58bd2924e15 is lower than any other,
similar autovac threshold. While we don't know exactly what value
will be optimal for all users, it is better to err a little on the
high side than on the low side. A higher value increases the risk
that users might exhaust the available space and start seeing errors
before autovacuum can clean things up sufficiently, but a user who
hits that problem can compensate for it by reducing
autovacuum_multixact_freeze_max_age to a value dependent on their
average multixact size. On the flip side, if the emergency cap
imposed by that patch kicks in too early, the user will experience
excessive wraparound scanning and will be unable to mitigate that
problem by configuration. The new value will hopefully reduce the
risk of such bad experiences while still providing enough headroom
to avoid multixact member exhaustion for most users.
Along the way, adjust the documentation to reflect the effects of
commit 04e6d3b877e060d8445eb653b7ea26b1ee5cec6b, which taught
autovacuum to run for multixact wraparound even when autovacuum
is configured off.
M doc/src/sgml/maintenance.sgml
M src/backend/access/transam/multixact.c
Even when autovacuum=off, force it for members as we do in other cases.
commit : 8ec1a3a541f66bed8deea0ab7b0b11687f1a0a8f
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 11 May 2015 10:51:14 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 11 May 2015 10:51:14 -0400
Thomas Munro, with some adjustments by me.
M src/backend/access/transam/multixact.c
Advance the stop point for multixact offset creation only at checkpoint.
commit : ded891916f7ae4ef2806a247c696940924e83745
author : Robert Haas <rhaas@postgresql.org>
date : Sun, 10 May 2015 22:21:20 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Sun, 10 May 2015 22:21:20 -0400
Commit b69bf30b9bfacafc733a9ba77c9587cf54d06c0c advanced the stop point
at vacuum time, but this has subsequently been shown to be unsafe as a
result of analysis by myself and Thomas Munro and testing by Thomas
Munro. The crux of the problem is that the SLRU deletion logic may
get confused about what to remove if, at exactly the right time during
the checkpoint process, the head of the SLRU crosses what used to be
the tail.
This patch, by me, fixes the problem by advancing the stop point only
following a checkpoint. This has the additional advantage of making
the removal logic work during recovery more like the way it works during
normal running, which is probably good.
At least one of the calls to DetermineSafeOldestOffset which this patch
removes was already dead, because MultiXactAdvanceOldest is called only
during recovery and DetermineSafeOldestOffset was set up to do nothing
during recovery. That, however, is inconsistent with the principle that
recovery and normal running should work similarly, and was confusing to
boot.
Along the way, fix some comments that previous patches in this area
neglected to update. It's not clear to me whether there's any
concrete basis for the decision to use only half of the multixact ID
space, but it's neither necessary nor sufficient to prevent multixact
member wraparound, so the comments should not say otherwise.
M src/backend/access/transam/multixact.c
Fix DetermineSafeOldestOffset for the case where there are no mxacts.
commit : 7b3f0f8b8ac2278d29e39b685d7c84ccd6ce1e93
author : Robert Haas <rhaas@postgresql.org>
date : Sun, 10 May 2015 21:34:26 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Sun, 10 May 2015 21:34:26 -0400
Commit b69bf30b9bfacafc733a9ba77c9587cf54d06c0c failed to take into
account the possibility that there might be no multixacts in existence
at all.
Report by Thomas Munro; patch by me.
M src/backend/access/transam/multixact.c
Recommend include_realm=1 in docs
commit : c106f397d1199b1f835c2dbbfceb1907822afd00
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 8 May 2015 19:39:52 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 8 May 2015 19:39:52 -0400
As discussed, the default setting of include_realm=0 can be dangerous in
multi-realm environments because it is then impossible to differentiate
users with the same username but who are from two different realms.
Recommend include_realm=1 and note that the default setting may change
in a future version of PostgreSQL and therefore users may wish to
explicitly set include_realm to avoid issues while upgrading.
M doc/src/sgml/client-auth.sgml
Teach autovacuum about multixact member wraparound.
commit : 3ecab37d97ed72bf81fd042dcef10e7111369875
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 8 May 2015 12:09:14 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 8 May 2015 12:09:14 -0400
The logic introduced in commit b69bf30b9bfacafc733a9ba77c9587cf54d06c0c
and repaired in commits 669c7d20e6374850593cb430d332e11a3992bbcf and
7be47c56af3d3013955c91c2877c08f2a0e3e6a2 helps to ensure that we don't
overwrite old multixact member information while it is still needed,
but a user who creates many large multixacts can still exhaust the
member space (and thus start getting errors) while autovacuum stands
idly by.
To fix this, progressively ramp down the effective value (but not the
actual contents) of autovacuum_multixact_freeze_max_age as member space
utilization increases. This makes autovacuum more aggressive and also
reduces the threshold for a manual VACUUM to perform a full-table scan.
This patch leaves unsolved the problem of ensuring that emergency
autovacuums are triggered even when autovacuum=off. We'll need to fix
that via a separate patch.
Thomas Munro and Robert Haas
M doc/src/sgml/maintenance.sgml
M src/backend/access/transam/multixact.c
M src/backend/commands/vacuum.c
M src/backend/postmaster/autovacuum.c
M src/include/access/multixact.h
Fix incorrect math in DetermineSafeOldestOffset.
commit : 32c50af4cf595b609878c160db67bef8ceaaa3c8
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 7 May 2015 11:00:47 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 7 May 2015 11:00:47 -0400
The old formula didn't have enough parentheses, so it would do the wrong
thing, and it used / rather than % to find a remainder. The effect of
these oversights is that the stop point chosen by the logic introduced in
commit b69bf30b9bfacafc733a9ba77c9587cf54d06c0c might be rather
meaningless.
Thomas Munro, reviewed by Kevin Grittner, with a whitespace tweak by me.
M src/backend/access/transam/multixact.c
Properly send SCM status updates when shutting down service on Windows
commit : 43ed06816f8d9c591ca767a19d555044648cb8a2
author : Magnus Hagander <magnus@hagander.net>
date : Thu, 7 May 2015 15:04:13 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Thu, 7 May 2015 15:04:13 +0200
The Service Control Manager should be notified regularly during a shutdown
that takes a long time. Previously we would increaes the counter, but forgot
to actually send the notification to the system. The loop counter was also
incorrectly initalized in the event that the startup of the system took long
enough for it to increase, which could cause the shutdown process not to wait
as long as expected.
Krystian Bigaj, reviewed by Michael Paquier
M src/bin/pg_ctl/pg_ctl.c
citext's regexp_matches() functions weren't documented, either.
commit : 6d78a179bfff068706198b5479f75c052fd2e005
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 May 2015 16:11:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 May 2015 16:11:01 -0400
M doc/src/sgml/citext.sgml
Fix incorrect declaration of citext's regexp_matches() functions.
commit : b1ec45994e5108d734c45876c25593823fcf8644
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 May 2015 15:50:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 May 2015 15:50:53 -0400
These functions should return SETOF TEXT[], like the core functions they
are wrappers for; but they were incorrectly declared as returning just
TEXT[]. This mistake had two results: first, if there was no match you got
a scalar null result, whereas what you should get is an empty set (zero
rows). Second, the 'g' flag was effectively ignored, since you would get
only one result array even if there were multiple matches, as reported by
Jeff Certain.
While ignoring 'g' is a clear bug, the behavior for no matches might well
have been thought to be the intended behavior by people who hadn't compared
it carefully to the core regexp_matches() functions. So we should tread
carefully about introducing this change in the back branches. Still, it
clearly is a bug and so providing some fix is desirable.
After discussion, the conclusion was to introduce the change in a 1.1
version of the citext extension (as we would need to do anyway); 1.0 still
contains the incorrect behavior. 1.1 is the default and only available
version in HEAD, but it is optional in the back branches, where 1.0 remains
the default version. People wishing to adopt the fix in back branches will
need to explicitly do ALTER EXTENSION citext UPDATE TO '1.1'. (I also
provided a downgrade script in the back branches, so people could go back
to 1.0 if necessary.)
This should be called out as an incompatible change in the 9.5 release
notes, although we'll also document it in the next set of back-branch
release notes. The notes should mention that any views or rules that use
citext's regexp_matches() functions will need to be dropped before
upgrading to 1.1, and then recreated again afterwards.
Back-patch to 9.1. The bug goes all the way back to citext's introduction
in 8.4, but pre-9.1 there is no extension mechanism with which to manage
the change. Given the lack of previous complaints it seems unnecessary to
change this behavior in 9.0, anyway.
M contrib/citext/Makefile
A contrib/citext/citext–1.0–1.1.sql
A contrib/citext/citext–1.1–1.0.sql
A contrib/citext/citext–1.1.sql
Fix some problems with patch to fsync the data directory.
commit : 603fe0181ad083ddc83f291fdce8ddc43d617154
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 5 May 2015 08:30:28 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 5 May 2015 08:30:28 -0400
pg_win32_is_junction() was a typo for pgwin32_is_junction(). open()
was used not only in a two-argument form, which breaks on Windows,
but also where BasicOpenFile() should have been used.
Per reports from Andrew Dunstan and David Rowley.
M src/backend/storage/file/fd.c
Recursively fsync() the data directory after a crash.
commit : d8ac77ab178ddb2ae043b8c463cd30c031e793d0
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 4 May 2015 14:13:53 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 4 May 2015 14:13:53 -0400
Otherwise, if there's another crash, some writes from after the first
crash might make it to disk while writes from before the crash fail
to make it to disk. This could lead to data corruption.
Back-patch to all supported versions.
Abhijit Menon-Sen, reviewed by Andres Freund and slightly revised
by me.
M src/backend/access/transam/xlog.c
M src/backend/storage/file/fd.c
M src/include/storage/fd.h
Fix two small bugs in json's populate_record_worker
commit : 997066f4456c0fc582e62a50e296c77360212049
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 4 May 2015 12:38:58 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 4 May 2015 12:38:58 -0400
The first bug is not releasing a tupdesc when doing an early return out
of the function. The second bug is a logic error in choosing when to do
an early return if given an empty jsonb object.
Bug reports from Pavel Stehule and Tom Lane respectively.
Backpatch to 9.4 where these were introduced.
M src/backend/utils/adt/jsonfuncs.c
Fix overlooked relcache invalidation in ALTER TABLE ... ALTER CONSTRAINT.
commit : 79edb298128b00161944b0e2cb6ef2460b717a7a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 May 2015 11:30:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 May 2015 11:30:24 -0400
When altering the deferredness state of a foreign key constraint, we
correctly updated the catalogs and then invalidated the relcache state for
the target relation ... but that's not the only relation with relevant
triggers. Must invalidate the other table as well, or the state change
fails to take effect promptly for operations triggered on the other table.
Per bug #13224 from Christian Ullrich.
In passing, reorganize regression test case for this feature so that it
isn't randomly injected into the middle of an unrelated test sequence.
Oversight in commit f177cbfe676dc2c7ca2b206c54d6bf819feeea8b. Back-patch
to 9.4 where the faulty code was added.
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Mark views created from tables as replication identity 'nothing'
commit : 70fac48446b3966050b73f6461e1404549672a8f
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 1 May 2015 13:03:23 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 1 May 2015 13:03:23 -0400
pg_dump turns tables into views using a method that was not setting
pg_class.relreplident properly.
Patch by Marko Tiikkaja
Backpatch through 9.4
M src/backend/rewrite/rewriteDefine.c
Fix pg_upgrade's multixact handling (again)
commit : 7140e11d8a81c988dc2f7369aaa1fd6ba276fb9e
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 30 Apr 2015 13:55:06 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 30 Apr 2015 13:55:06 -0300
We need to create the pg_multixact/offsets file deleted by pg_upgrade
much earlier than we originally were: it was in TrimMultiXact(), which
runs after we exit recovery, but it actually needs to run earlier than
the first call to SetMultiXactIdLimit (before recovery), because that
routine already wants to read the first offset segment.
Per pg_upgrade trouble report from Jeff Janes.
While at it, silence a compiler warning about a pointless assert that an
unsigned variable was being tested non-negative. This was a signed
constant in Thomas Munro's patch which I changed to unsigned before
commit. Pointed out by Andres Freund.
M src/backend/access/transam/multixact.c
Code review for multixact bugfix
commit : 9ae6c11f97babdac4d52b5d86ea0f1636abe37fd
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 28 Apr 2015 14:52:29 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 28 Apr 2015 14:52:29 -0300
Reword messages, rename a confusingly named function.
Per Robert Haas.
M src/backend/access/transam/multixact.c
Protect against multixact members wraparound
commit : 942542cbbae5b38a1cf7c9caf29a491d0faaba8f
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 28 Apr 2015 11:32:53 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 28 Apr 2015 11:32:53 -0300
Multixact member files are subject to early wraparound overflow and
removal: if the average multixact size is above a certain threshold (see
note below) the protections against offset overflow are not enough:
during multixact truncation at checkpoint time, some
pg_multixact/members files would be removed because the server considers
them to be old and not needed anymore. This leads to loss of files that
are critical to interpret existing tuples's Xmax values.
To protect against this, since we don't have enough info in pg_control
and we can't modify it in old branches, we maintain shared memory state
about the oldest value that we need to keep; we use this during new
multixact creation to abort if an old still-needed file would get
overwritten. This value is kept up to date by checkpoints, which makes
it not completely accurate but should be good enough. We start emitting
warnings sometime earlier, so that the eventual multixact-shutdown
doesn't take DBAs completely by surprise (more precisely: once 20
members SLRU segments are remaining before shutdown.)
On troublesome average multixact size: The threshold size depends on the
multixact freeze parameters. The oldest age is related to the greater of
multixact_freeze_table_age and multixact_freeze_min_age: anything
older than that should be removed promptly by autovacuum. If autovacuum
is keeping up with multixact freezing, the troublesome multixact average
size is
(2^32-1) / Max(freeze table age, freeze min age)
or around 28 members per multixact. Having an average multixact size
larger than that will eventually cause new multixact data to overwrite
the data area for older multixacts. (If autovacuum is not able to keep
up, or there are errors in vacuuming, the actual maximum is
multixact_freeeze_max_age instead, at which point multixact generation
is stopped completely. The default value for this limit is 400 million,
which means that the multixact size that would cause trouble is about 10
members).
Initial bug report by Timothy Garnett, bug #12990
Backpatch to 9.3, where the problem was introduced.
Authors: Álvaro Herrera, Thomas Munro
Reviews: Thomas Munro, Amit Kapila, Robert Haas, Kevin Grittner
M src/backend/access/transam/multixact.c
M src/backend/bootstrap/bootstrap.c
Use a fd opened for read/write when syncing slots during startup.
commit : fd3dfc236c155048caf21c35e23e8dadc89895ec
author : Andres Freund <andres@anarazel.de>
date : Tue, 28 Apr 2015 00:12:38 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 28 Apr 2015 00:12:38 +0200
Some operating systems, including the reporter's windows, return EBADFD
or similar when fsync() is invoked on a O_RDONLY file descriptor.
Unfortunately RestoreSlotFromDisk() does exactly that; which causes
failures after restarts in at least some scenarios.
If you hit the bug the error message will be something like
ERROR: could not fsync file "pg_replslot/$name/state": Bad file descriptor
Simply use O_RDWR instead of O_RDONLY when opening the relevant file
descriptor to fix the bug. Unfortunately I have no way of verifying the
fix, but we've seen similar problems in the past.
This bug goes back to 9.4 where slots were introduced. Backpatch
accordingly.
Reported-By: Patrice Drolet
Bug: #13143:
Discussion: 20150424101006.2556.60897@wrigleys.postgresql.org
M src/backend/replication/slot.c
Prevent improper reordering of antijoins vs. outer joins.
commit : 5f3d1909c58aee1911d4b1e7f643bb8db09e8da6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Apr 2015 16:44:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Apr 2015 16:44:27 -0400
An outer join appearing within the RHS of an antijoin can't commute with
the antijoin, but somehow I missed teaching make_outerjoininfo() about
that. In Teodor Sigaev's recent trouble report, this manifests as a
"could not find RelOptInfo for given relids" error within eqjoinsel();
but I think silently wrong query results are possible too, if the planner
misorders the joins and doesn't happen to trigger any internal consistency
checks. It's broken as far back as we had antijoins, so back-patch to all
supported branches.
M src/backend/optimizer/plan/initsplan.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Build every ECPG library with -DFRONTEND.
commit : 0a5570e3684adeb50c06e197e59dff9f829e67e6
author : Noah Misch <noah@leadboat.com>
date : Fri, 24 Apr 2015 19:29:02 -0400
committer: Noah Misch <noah@leadboat.com>
date : Fri, 24 Apr 2015 19:29:02 -0400
Each of the libraries incorporates src/port files, which often check
FRONTEND. Build systems disagreed on whether to build libpgtypes this
way. Only libecpg incorporates files that rely on it today. Back-patch
to 9.0 (all supported versions) to forestall surprises.
M src/interfaces/ecpg/compatlib/Makefile
M src/interfaces/ecpg/pgtypeslib/Makefile
M src/tools/msvc/Mkvcbuild.pm
Fix obsolete comment in set_rel_size().
commit : d3398d085dfbc2cfea98b4b57a96be780058b6ff
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 24 Apr 2015 15:18:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 24 Apr 2015 15:18:07 -0400
The cross-reference to set_append_rel_pathlist() was obsoleted by
commit e2fa76d80ba571d4de8992de6386536867250474, which split what
had been set_rel_pathlist() and child routines into two sets of
functions. But I (tgl) evidently missed updating this comment.
Back-patch to 9.2 to avoid unnecessary divergence among branches.
Amit Langote
M src/backend/optimizer/path/allpaths.c
Fix deadlock at startup, if max_prepared_transactions is too small.
commit : 438a062d54035febf4769618950d11eda48247c4
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 23 Apr 2015 21:25:44 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 23 Apr 2015 21:25:44 +0300
When the startup process recovers transactions by scanning pg_twophase
directory, it should clear MyLockedGxact after it's done processing each
transaction. Like we do during normal operation, at PREPARE TRANSACTION.
Otherwise, if the startup process exits due to an error, it will try to
clear the locking_backend field of the last recovered transaction. That's
usually harmless, but if the error happens in MarkAsPreparing, while
holding TwoPhaseStateLock, the shmem-exit hook will try to acquire
TwoPhaseStateLock again, and deadlock with itself.
This fixes bug #13128 reported by Grant McAlister. The bug was introduced
by commit bb38fb0d, so backpatch to all supported versions like that
commit.
M src/backend/access/transam/twophase.c
pg_upgrade: document need for text search files to be copied
commit : 7f2bfebfa75804b060a9ff4968711743e5450829
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 16 Apr 2015 21:38:00 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 16 Apr 2015 21:38:00 -0400
Report by CJ Estel
Backpatch through 9.4
M doc/src/sgml/pgupgrade.sgml
Fix typo in comment
commit : 292ea1057364fe818e026c2cd8b8e81d62f8140b
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 14 Apr 2015 12:12:18 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 14 Apr 2015 12:12:18 -0300
SLRU_SEGMENTS_PER_PAGE -> SLRU_PAGES_PER_SEGMENT
I introduced this ancient typo in subtrans.c and later propagated it to
multixact.c. I fixed the latter in f741300c, but only back to 9.3;
backpatch to all supported branches for consistency.
M src/backend/access/transam/subtrans.c
Don't archive bogus recycled or preallocated files after timeline switch.
commit : d72792d0213ec352cdb71f3994a53194bc00f220
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 13 Apr 2015 16:53:49 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 13 Apr 2015 16:53:49 +0300
After a timeline switch, we would leave behind recycled WAL segments that
are in the future, but on the old timeline. After promotion, and after they
become old enough to be recycled again, we would notice that they don't have
a .ready or .done file, create a .ready file for them, and archive them.
That's bogus, because the files contain garbage, recycled from an older
timeline (or prealloced as zeros). We shouldn't archive such files.
This could happen when we're following a timeline switch during replay, or
when we switch to new timeline at end-of-recovery.
To fix, whenever we switch to a new timeline, scan the data directory for
WAL segments on the old timeline, but with a higher segment number, and
remove them. Those don't belong to our timeline history, and are most
likely bogus recycled or preallocated files. They could also be valid files
that we streamed from the primary ahead of time, but in any case, they're
not needed to recover to the new timeline.
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogarchive.c
M src/include/access/xlog_internal.h
Remove duplicated words in comments.
commit : 131fb7fc66332b4c13cab2f1a5a87aab0767ebd9
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 12 Apr 2015 10:46:17 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 12 Apr 2015 10:46:17 +0300
David Rowley
M src/backend/replication/walsender.c
M src/bin/pg_basebackup/pg_basebackup.c
Fix incorrect punctuation
commit : bdd66849683c7b77c000cdf0bb69bbc64b10a01c
author : Magnus Hagander <magnus@hagander.net>
date : Thu, 9 Apr 2015 13:35:30 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Thu, 9 Apr 2015 13:35:30 +0200
Amit Langote
M doc/src/sgml/mvcc.sgml
Fix autovacuum launcher shutdown sequence
commit : ec01c1c0a4b3992852f7e1980915f0869498ff69
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 8 Apr 2015 13:19:49 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 8 Apr 2015 13:19:49 -0300
It was previously possible to have the launcher re-execute its main loop
before shutting down if some other signal was received or an error
occurred after getting SIGTERM, as reported by Qingqing Zhou.
While investigating, Tom Lane further noticed that if autovacuum had
been disabled in the config file, it would misbehave by trying to start
a new worker instead of bailing out immediately -- it would consider
itself as invoked in emergency mode.
Fix both problems by checking the shutdown flag in a few more places.
These problems have existed since autovacuum was introduced, so
backpatch all the way back.
M src/backend/postmaster/autovacuum.c
Fix assorted inconsistent function declarations.
commit : f97a0a2cc4bb029533db4e142a51717f24096de2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Apr 2015 16:56:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Apr 2015 16:56:21 -0400
While gcc doesn't complain if you declare a function "static" and then
define it not-static, other compilers do; and in any case the code is
highly misleading this way. Add the missing "static" keywords to a
couple of recent patches. Per buildfarm member pademelon.
M contrib/pg_upgrade/pg_upgrade.c
M src/bin/pg_resetxlog/pg_resetxlog.c
Fix spelling of author's name
commit : 8e003bc6afd2847a8458841e8ca35b94f4a59a66
author : Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 7 Apr 2015 14:05:05 -0400
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 7 Apr 2015 14:05:05 -0400
M doc/src/sgml/release-9.4.sgml
Fix typo in libpq.sgml.
commit : ee679285dd7524f2836d06df9373f366230f3454
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 6 Apr 2015 12:15:20 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 6 Apr 2015 12:15:20 +0900
Back-patch to all supported versions.
Michael Paquier
M doc/src/sgml/libpq.sgml
Suppress clang's unhelpful gripes about -pthread switch being unused.
commit : 8972a152c597cf88280c6a99b03f38cbf21e6dd2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Apr 2015 13:01:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Apr 2015 13:01:55 -0400
Considering the number of cases in which "unused" command line arguments
are silently ignored by compilers, it's fairly astonishing that anybody
thought this warning was useful; it's certainly nothing but an annoyance
when building Postgres. One such case is that neither gcc nor clang
complain about unrecognized -Wno-foo switches, making it more difficult
to figure out whether the switch does anything than one could wish.
Back-patch to 9.3, which is as far back as the patch applies conveniently
(we'd have to back-patch PGAC_PROG_CC_VAR_OPT to go further, and it doesn't
seem worth that).
M configure
M configure.in
Fix incorrect matching of subexpressions in outer-join plan nodes.
commit : 1d71d36ffeae15616672b5c34e4f0d6f3484fa45
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 4 Apr 2015 19:55:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 4 Apr 2015 19:55:15 -0400
Previously we would re-use input subexpressions in all expression trees
attached to a Join plan node. However, if it's an outer join and the
subexpression appears in the nullable-side input, this is potentially
incorrect for apparently-matching subexpressions that came from above
the outer join (ie, targetlist and qpqual expressions), because the
executor will treat the subexpression value as NULL when maybe it should
not be.
The case is fairly hard to hit because (a) you need a non-strict
subexpression (else NULL is correct), and (b) we don't usually compute
expressions in the outputs of non-toplevel plan nodes. But we might do
so if the expressions are sort keys for a mergejoin, for example.
Probably in the long run we should make a more explicit distinction between
Vars appearing above and below an outer join, but that will be a major
planner redesign and not at all back-patchable. For the moment, just hack
set_join_references so that it will not match any non-Var expressions
coming from nullable inputs to expressions that came from above the join.
(This is somewhat overkill, in that a strict expression could still be
matched, but it doesn't seem worth the effort to check that.)
Per report from Qingqing Zhou. The added regression test case is based
on his example.
This has been broken for a very long time, so back-patch to all active
branches.
M src/backend/optimizer/plan/setrefs.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix TAP tests to use only standard command-line argument ordering.
commit : 406b2f0b4cbd1aa68334c2ed182e20e11cf47c62
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 4 Apr 2015 13:34:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 4 Apr 2015 13:34:23 -0400
Some of the TAP tests were supposing that PG programs would accept switches
after non-switch arguments on their command lines. While GNU getopt_long()
does allow that, our own implementation does not, and it's nowhere
suggested in our documentation that such cases should work. Adjust the
tests to use only the documented syntax.
Back-patch to 9.4, since without this the TAP tests fail when run with
src/port's getopt_long() implementation.
Michael Paquier
M src/bin/initdb/t/001_initdb.pl
M src/bin/scripts/t/010_clusterdb.pl
M src/bin/scripts/t/020_createdb.pl
M src/bin/scripts/t/090_reindexdb.pl
Remove unnecessary variables in _hash_splitbucket().
commit : c419321061420a6eb5851f2fdb0e0d5db24f5a4e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Apr 2015 16:49:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Apr 2015 16:49:11 -0400
Commit ed9cc2b5df59fdbc50cce37399e26b03ab2c1686 made it unnecessary to pass
start_nblkno to _hash_splitbucket(), and for that matter unnecessary to
have the internal nblkno variable either. My compiler didn't complain
about that, but some did. I also rearranged the use of oblkno a bit to
make that case more parallel.
Report and initial patch by Petr Jelinek, rearranged a bit by me.
Back-patch to all branches, like the previous patch.
M src/backend/access/hash/hashpage.c
Fix rare startup failure induced by MVCC-catalog-scans patch.
commit : ee0d06c0b9993fb06b940c21a7bfde7de8186a2e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Apr 2015 00:07:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Apr 2015 00:07:29 -0400
While a new backend nominally participates in sinval signaling starting
from the SharedInvalBackendInit call near the top of InitPostgres, it
cannot recognize sinval messages for unshared catalogs of its database
until it has set up MyDatabaseId. This is not problematic for the catcache
or relcache, which by definition won't have loaded any data from or about
such catalogs before that point. However, commit 568d4138c646cd7c
introduced a mechanism for re-using MVCC snapshots for catalog scans, and
made invalidation of those depend on recognizing relevant sinval messages.
So it's possible to establish a catalog snapshot to read pg_authid and
pg_database, then before we set MyDatabaseId, receive sinval messages that
should result in invalidating that snapshot --- but do not, because we
don't realize they are for our database. This mechanism explains the
intermittent buildfarm failures we've seen since commit 31eae6028eca4365.
That commit was not itself at fault, but it introduced a new regression
test that does reconnections concurrently with the "vacuum full pg_am"
command in vacuum.sql. This allowed the pre-existing error to be exposed,
given just the right timing, because we'd fail to update our information
about how to access pg_am. In principle any VACUUM FULL on a system
catalog could have created a similar hazard for concurrent incoming
connections. Perhaps there are more subtle failure cases as well.
To fix, force invalidation of the catalog snapshot as soon as we've
set MyDatabaseId.
Back-patch to 9.4 where the error was introduced.
M src/backend/utils/init/postinit.c
After a crash, don't restart workers with BGW_NEVER_RESTART.
commit : a1f4ade01ca625332a43434061f1b72788cb71e2
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 2 Apr 2015 14:38:06 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 2 Apr 2015 14:38:06 -0400
Amit Khandekar
M src/backend/postmaster/bgworker.c
Correct comment to use RS_EPHEMERAL
commit : 3ebe6d895624b0c2820a0043929250beaf3e6d8b
author : Simon Riggs <simon@2ndQuadrant.com>
date : Thu, 2 Apr 2015 07:49:48 -0400
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Thu, 2 Apr 2015 07:49:48 -0400
M src/backend/replication/slot.c
psql: fix \connect with URIs and conninfo strings
commit : a44e54cf4b75159025ca8ff769c754123feb96a5
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 1 Apr 2015 20:00:07 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 1 Apr 2015 20:00:07 -0300
psql was already accepting conninfo strings as the first parameter in
\connect, but the way it worked wasn't sane; some of the other
parameters would get the previous connection's values, causing it to
connect to a completely unexpected server or, more likely, not finding
any server at all because of completely wrong combinations of
parameters.
Fix by explicitely checking for a conninfo-looking parameter in the
dbname position; if one is found, use its complete specification rather
than mix with the other arguments. Also, change tab-completion to not
try to complete conninfo/URI-looking "dbnames" and document that
conninfos are accepted as first argument.
There was a weak consensus to backpatch this, because while the behavior
of using the dbname as a conninfo is nowhere documented for \connect, it
is reasonable to expect that it works because it does work in many other
contexts. Therefore this is backpatched all the way back to 9.0.
To implement this, routines previously private to libpq have been
duplicated so that psql can decide what looks like a conninfo/URI
string. In back branches, just duplicate the same code all the way back
to 9.2, where URIs where introduced; 9.0 and 9.1 have a simpler version.
In master, the routines are moved to src/common and renamed.
Author: David Fetter, Andrew Dunstan. Some editorialization by me
(probably earning a Gierth's "Sloppy" badge in the process.)
Reviewers: Andrew Gierth, Erik Rijkers, Pavel Stěhule, Stephen Frost,
Robert Haas, Andrew Dunstan.
M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/command.c
M src/bin/psql/common.c
M src/bin/psql/common.h
M src/bin/psql/help.c
M src/bin/psql/tab-complete.c
Fix incorrect markup in documentation of window frame clauses.
commit : 68a8f26e91a15294024270eb3eed4468dbb307cf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Mar 2015 20:02:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Mar 2015 20:02:40 -0400
You're required to write either RANGE or ROWS to start a frame clause,
but the documentation incorrectly implied this is optional. Noted by
David Johnston.
M doc/src/sgml/ref/select.sgml
M doc/src/sgml/syntax.sgml
Remove spurious semicolons.
commit : 463712390778f7d3e256e52dc4d330266ee4f416
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 31 Mar 2015 15:12:27 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 31 Mar 2015 15:12:27 +0300
Petr Jelinek
M contrib/postgres_fdw/deparse.c
M src/backend/parser/gram.y
M src/backend/replication/repl_gram.y
M src/backend/utils/adt/json.c
M src/backend/utils/adt/jsonfuncs.c
M src/backend/utils/adt/oracle_compat.c
Run pg_upgrade and pg_resetxlog with restricted token on Windows
commit : 2366761bf9eb8e9aa3820b9f3491bcfc48b8188f
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 30 Mar 2015 17:16:57 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 30 Mar 2015 17:16:57 -0400
As with initdb these programs need to run with a restricted token, and
if they don't pg_upgrade will fail when run as a user with Adminstrator
privileges.
Backpatch to all live branches. On the development branch the code is
reorganized so that the restricted token code is now in a single
location. On the stable bramches a less invasive change is made by
simply copying the relevant code to pg_upgrade.c and pg_resetxlog.c.
Patches and bug report from Muhammad Asif Naeem, reviewed by Michael
Paquier, slightly edited by me.
M contrib/pg_upgrade/pg_upgrade.c
M src/bin/pg_resetxlog/pg_resetxlog.c
Fix bogus concurrent use of _hash_getnewbuf() in bucket split code.
commit : a6a8bf5cddabacfbd76d5161832c6272791b2503
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Mar 2015 16:40:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Mar 2015 16:40:05 -0400
_hash_splitbucket() obtained the base page of the new bucket by calling
_hash_getnewbuf(), but it held no exclusive lock that would prevent some
other process from calling _hash_getnewbuf() at the same time. This is
contrary to _hash_getnewbuf()'s API spec and could in fact cause failures.
In practice, we must only call that function while holding write lock on
the hash index's metapage.
An additional problem was that we'd already modified the metapage's bucket
mapping data, meaning that failure to extend the index would leave us with
a corrupt index.
Fix both issues by moving the _hash_getnewbuf() call to just before we
modify the metapage in _hash_expandtable().
Unfortunately there's still a large problem here, which is that we could
also incur ENOSPC while trying to get an overflow page for the new bucket.
That would leave the index corrupt in a more subtle way, namely that some
index tuples that should be in the new bucket might still be in the old
one. Fixing that seems substantially more difficult; even preallocating as
many pages as we could possibly need wouldn't entirely guarantee that the
bucket split would complete successfully. So for today let's just deal
with the base case.
Per report from Antonin Houska. Back-patch to all active branches.
M src/backend/access/hash/hashpage.c
Fix rare core dump in BackendIdGetTransactionIds().
commit : 2897e069c1f4309a237a1fa4bf5d2fcd9c4b9868
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Mar 2015 13:05:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Mar 2015 13:05:27 -0400
BackendIdGetTransactionIds() neglected the possibility that the PROC
pointer in a ProcState array entry is null. In current usage, this could
only crash if the other backend had exited since pgstat_read_current_status
saw it as active, which is a pretty narrow window. But it's reachable in
the field, per bug #12918 from Vladimir Borodin.
Back-patch to 9.4 where the faulty code was introduced.
M src/backend/storage/ipc/sinvaladt.c
Add vacuum_delay_point call in compute_index_stats's per-sample-row loop.
commit : f444de5e34f673043b948e14ad3f76a30f698ecb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 29 Mar 2015 15:04:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 29 Mar 2015 15:04:09 -0400
Slow functions in index expressions might cause this loop to take long
enough to make it worth being cancellable. Probably it would be enough
to call CHECK_FOR_INTERRUPTS here, but for consistency with other
per-sample-row loops in this file, let's use vacuum_delay_point.
Report and patch by Jeff Janes. Back-patch to all supported branches.
M src/backend/commands/analyze.c
Make SyncRepWakeQueue to a static function
commit : 3740bb8347a946232ad281174398a825c1b40c73
author : Tatsuo Ishii <ishii@postgresql.org>
date : Thu, 26 Mar 2015 10:38:11 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Thu, 26 Mar 2015 10:38:11 +0900
It is only used in src/backend/replication/syncrep.c.
Back-patch to all supported branches except 9.1 which declares the
function as static.
M src/backend/replication/syncrep.c
M src/include/replication/syncrep.h
Fix ExecOpenScanRelation to take a lock on a ROW_MARK_COPY relation.
commit : 3171edddc4b8386e0f0ee2a68bb4b253d79444fc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 24 Mar 2015 15:53:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 24 Mar 2015 15:53:06 -0400
ExecOpenScanRelation assumed that any relation listed in the ExecRowMark
list has been locked by InitPlan; but this is not true if the rel's
markType is ROW_MARK_COPY, which is possible if it's a foreign table.
In most (possibly all) cases, failure to acquire a lock here isn't really
problematic because the parser, planner, or plancache would have taken the
appropriate lock already. In principle though it might leave us vulnerable
to working with a relation that we hold no lock on, and in any case if the
executor isn't depending on previously-taken locks otherwise then it should
not do so for ROW_MARK_COPY relations.
Noted by Etsuro Fujita. Back-patch to all active versions, since the
inconsistency has been there a long time. (It's almost certainly
irrelevant in 9.0, since that predates foreign tables, but the code's
still wrong on its own terms.)
M src/backend/executor/execMain.c
M src/backend/executor/execUtils.c
Don't delay replication for less than recovery_min_apply_delay's resolution.
commit : 16be9737cc3d5f7da599a5c2fe2ff975db296f3b
author : Andres Freund <andres@anarazel.de>
date : Mon, 23 Mar 2015 16:40:10 +0100
committer: Andres Freund <andres@anarazel.de>
date : Mon, 23 Mar 2015 16:40:10 +0100
Recovery delays are implemented by waiting on a latch, and latches take
milliseconds as a parameter. The required amount of waiting was computed
using microsecond resolution though and the wait loop's abort condition
was checking the delay in microseconds as well. This could lead to
short spurts of busy looping when the overall wait time was below a
millisecond, but above 0 microseconds.
Instead just formulate the wait loop's abort condition in millisecond
granularity as well. Given that that's recovery_min_apply_delay
resolution, it seems harmless to not wait for less than a millisecond.
Backpatch to 9.4 where recovery_min_apply_delay was introduced.
Discussion: 20150323141819.GH26995@alap3.anarazel.de
M src/backend/access/transam/xlog.c
Fix status reporting for terminated bgworkers that were never started.
commit : 76d07a2a0633836a82c43beb8ed3b08a64dc3d46
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 19 Mar 2015 10:56:34 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 19 Mar 2015 10:56:34 -0400
Previously, GetBackgroundWorkerPid() would return BGWH_NOT_YET_STARTED
if the slot used for the worker registration had not been reused by
unrelated activity, and BGWH_STOPPED if it had. Either way, a process
that had requested notification when the state of one of its
background workers changed did not receive such notifications. Fix
things so that GetBackgroundWorkerPid() always returns BGWH_STOPPED in
this situation, so that we do not erroneously give waiters the
impression that the worker will eventually be started; and send
notifications just as we would if the process terminated after having
been started, so that it's possible to wait for the postmaster to
process a worker termination request without polling.
Discovered by Amit Kapila during testing of parallel sequential scan.
Analysis and fix by me. Back-patch to 9.4; there may not be anyone
relying on this interface yet, but if anyone is, the new behavior is a
clear improvement.
M src/backend/postmaster/bgworker.c
Replace insertion sort in contrib/intarray with qsort().
commit : 904e8b627c2547e93112080aac9381bbf39e8e99
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Mar 2015 23:22:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Mar 2015 23:22:03 -0400
It's all very well to claim that a simplistic sort is fast in easy
cases, but O(N^2) in the worst case is not good ... especially if the
worst case is as easy to hit as "descending order input". Replace that
bit with our standard qsort.
Per bug #12866 from Maksym Boguk. Back-patch to all active branches.
M contrib/intarray/_int_tool.c
src/port/dirmod.c needs to be built on Cygwin too.
commit : 837eb0846190bef65575b642a0ee8a3b3fedbafe
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Mar 2015 14:14:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Mar 2015 14:14:24 -0400
Oversight in my commit 91f4a5a976500517e492320e389342d7436cf9d4.
Per buildfarm member brolga.
M configure
M configure.in
Build src/port/dirmod.c only on Windows.
commit : c415c13b7ef68c7f8626f74a8e593af2a5a766b9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 14 Mar 2015 14:08:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 14 Mar 2015 14:08:45 -0400
Since commit ba7c5975adea74c6f17bdb0e0427ad85962092a2, port/dirmod.c
has contained only Windows-specific functions. Most platforms don't
seem to mind uselessly building an empty file, but OS X for one issues
warnings. Hence, treat dirmod.c as a Windows-specific file selected
by configure rather than one that's always built. We can revert this
change if dirmod.c ever gains any non-Windows functionality again.
Back-patch to 9.4 where the mentioned commit appeared.
M configure
M configure.in
M src/include/port.h
M src/port/Makefile
Remove workaround for ancient incompatibility between readline and libedit.
commit : f50b5c7d0dfd997ec93c29d54dfe4f63a224ab23
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 14 Mar 2015 13:43:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 14 Mar 2015 13:43:00 -0400
GNU readline defines the return value of write_history() as "zero if OK,
else an errno code". libedit's version of that function used to have a
different definition (to wit, "-1 if error, else the number of lines
written to the file"). We tried to work around that by checking whether
errno had become nonzero, but this method has never been kosher according
to the published API of either library. It's reportedly completely broken
in recent Ubuntu releases: psql bleats about "No such file or directory"
when saving ~/.psql_history, even though the write worked fine.
However, libedit has been following the readline definition since somewhere
around 2006, so it seems all right to finally break compatibility with
ancient libedit releases and trust that the return value is what readline
specifies. (I'm not sure when the various Linux distributions incorporated
this fix, but I did find that OS X has been shipping fixed versions since
10.5/Leopard.)
If anyone is still using such an ancient libedit, they will find that psql
complains it can't write ~/.psql_history at exit, even when the file was
written correctly. This is no worse than the behavior we're fixing for
current releases.
Back-patch to all supported branches.
M src/bin/psql/input.c
Fix integer overflow in debug message of walreceiver
commit : 432478597957ccbd80aea8ad2befeb67db2f6564
author : Tatsuo Ishii <ishii@postgresql.org>
date : Sat, 14 Mar 2015 08:16:50 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Sat, 14 Mar 2015 08:16:50 +0900
The message tries to tell the replication apply delay which fails if
the first WAL record is not applied yet. Fix is, instead of telling
overflowed minus numeric, showing "N/A" which indicates that the delay
data is not yet available. Problem reported by me and patch by
Fabrízio de Royes Mello.
Back patched to 9.4, 9.3 and 9.2 stable branches (9.1 and 9.0 do not
have the debug message).
M src/backend/replication/walreceiver.c
M src/backend/replication/walreceiverfuncs.c
Ensure tableoid reads correctly in EvalPlanQual-manufactured tuples.
commit : 32269be59efc740ca8c800b348d8ea8098d91ab2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Mar 2015 13:38:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Mar 2015 13:38:49 -0400
The ROW_MARK_COPY path in EvalPlanQualFetchRowMarks() was just setting
tableoid to InvalidOid, I think on the assumption that the referenced
RTE must be a subquery or other case without a meaningful OID. However,
foreign tables also use this code path, and they do have meaningful
table OIDs; so failure to set the tuple field can lead to user-visible
misbehavior. Fix that by fetching the appropriate OID from the range
table.
There's still an issue about whether CTID can ever have a meaningful
value in this case; at least with postgres_fdw foreign tables, it does.
But that is a different problem that seems to require a significantly
different patch --- it's debatable whether postgres_fdw really wants to
use this code path at all.
Simplified version of a patch by Etsuro Fujita, who also noted the
problem to begin with. The issue can be demonstrated in all versions
having FDWs, so back-patch to 9.1.
M src/backend/executor/execMain.c
Fix memory leaks in GIN index vacuum.
commit : d810720262983215ac407935bfb8940e43dc33a0
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 12 Mar 2015 15:29:58 +0100
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 12 Mar 2015 15:29:58 +0100
Per bug #12850 by Walter Nordmann. Backpatch to 9.4 where the leak was
introduced.
M src/backend/access/gin/ginvacuum.c
Cast to (void *) rather than (int *) when passing int64's to PQfn().
commit : 3d0d3c02fff4d0c919eed28fb0d6d4b45857a408
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Mar 2015 13:58:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Mar 2015 13:58:28 -0400
This is a possibly-vain effort to silence a Coverity warning about
bogus endianness dependency. The code's fine, because it takes care
of endianness issues for itself, but Coverity sees an int64 being
passed to an int* argument and not unreasonably suspects something's
wrong. I'm not sure if putting the void* cast in the way will shut it
up; but it can't hurt and seems better from a documentation standpoint
anyway, since the pointer is not used as an int* in this code path.
Just for a bit of additional safety, verify that the result length
is 8 bytes as expected.
Back-patch to 9.3 where the code in question was added.
M src/interfaces/libpq/fe-lobj.c
Fix documentation for libpq's PQfn().
commit : 089e5ab1f8aaf1dd370624cf22be0780d94e24a2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Mar 2015 13:35:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Mar 2015 13:35:28 -0400
The SGML docs claimed that 1-byte integers could be sent or received with
the "isint" options, but no such behavior has ever been implemented in
pqGetInt() or pqPutInt(). The in-code documentation header for PQfn() was
even less in tune with reality, and the code itself used parameter names
matching neither the SGML docs nor its libpq-fe.h declaration. Do a bit
of additional wordsmithing on the SGML docs while at it.
Since the business about 1-byte integers is a clear documentation bug,
back-patch to all supported branches.
M doc/src/sgml/libpq.sgml
M src/interfaces/libpq/fe-exec.c
Rethink function argument sorting in pg_dump.
commit : 629f8613f02239c69f20a42f00a548e808962415
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 Mar 2015 13:27:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 Mar 2015 13:27:46 -0500
Commit 7b583b20b1c95acb621c71251150beef958bb603 created an unnecessary
dump failure hazard by applying pg_get_function_identity_arguments()
to every function in the database, even those that won't get dumped.
This could result in snapshot-related problems if concurrent sessions are,
for example, creating and dropping temporary functions, as noted by Marko
Tiikkaja in bug #12832. While this is by no means pg_dump's only such
issue with concurrent DDL, it's unfortunate that we added a new failure
mode for cases that used to work, and even more so that the failure was
created for basically cosmetic reasons (ie, to sort overloaded functions
more deterministically).
To fix, revert that patch and instead sort function arguments using
information that pg_dump has available anyway, namely the names of the
argument types. This will produce a slightly different sort ordering for
overloaded functions than the previous coding; but applying strcmp
directly to the output of pg_get_function_identity_arguments really was
a bit odd anyway. The sorting will still be name-based and hence
independent of possibly-installation-specific OID assignments. A small
additional benefit is that sorting now works regardless of server version.
Back-patch to 9.3, where the previous commit appeared.
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/pg_dump/pg_dump_sort.c
Fix contrib/file_fdw's expected file
commit : 0deecc2b6fb194764df56079049cf29f1c933063
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 6 Mar 2015 11:47:09 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 6 Mar 2015 11:47:09 -0300
I forgot to update it on yesterday's cf34e373fcf.
M contrib/file_fdw/output/file_fdw.source
Fix user mapping object description
commit : 74997763486797142c6636dc72c03510477d1e6c
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 5 Mar 2015 18:03:16 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 5 Mar 2015 18:03:16 -0300
We were using "user mapping for user XYZ" as description for user mappings, but
that's ambiguous because users can have mappings on multiple foreign
servers; therefore change it to "for user XYZ on server UVW" instead.
Object identities for user mappings are also updated in the same way, in
branches 9.3 and above.
The incomplete description string was introduced together with the whole
SQL/MED infrastructure by commit cae565e503 of 8.4 era, so backpatch all
the way back.
M src/backend/catalog/objectaddress.c
M src/test/regress/expected/foreign_data.out
Add comment for "is_internal" parameter
commit : 2570e28827e3ac4a316300f92dfaf448e55c8e0c
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 3 Mar 2015 14:03:33 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 3 Mar 2015 14:03:33 -0300
This was missed in my commit f4c4335 of 9.3 vintage, so backpatch to
that.
M src/backend/catalog/heap.c
Fix pg_dump handling of extension config tables
commit : c05fa34333f62de2641102600b5874a395cb289a
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 2 Mar 2015 14:12:28 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 2 Mar 2015 14:12:28 -0500
Since 9.1, we've provided extensions with a way to denote
"configuration" tables- tables created by an extension which the user
may modify. By marking these as "configuration" tables, the extension
is asking for the data in these tables to be pg_dump'd (tables which
are not marked in this way are assumed to be entirely handled during
CREATE EXTENSION and are not included at all in a pg_dump).
Unfortunately, pg_dump neglected to consider foreign key relationships
between extension configuration tables and therefore could end up
trying to reload the data in an order which would cause FK violations.
This patch teaches pg_dump about these dependencies, so that the data
dumped out is done so in the best order possible. Note that there's no
way to handle circular dependencies, but those have yet to be seen in
the wild.
The release notes for this should include a caution to users that
existing pg_dump-based backups may be invalid due to this issue. The
data is all there, but restoring from it will require extracting the
data for the configuration tables and then loading them in the correct
order by hand.
Discussed initially back in bug #6738, more recently brought up by
Gilles Darold, who provided an initial patch which was further reworked
by Michael Paquier. Further modifications and documentation updates
by me.
Back-patch to 9.1 where we added the concept of extension configuration
tables.
M doc/src/sgml/extend.sgml
M src/bin/pg_dump/pg_dump.c
Fix targetRelation initializiation in prepsecurity
commit : 99ccda339acc165d0bdfba34a62fe87cbe6f4068
author : Stephen Frost <sfrost@snowman.net>
date : Sun, 1 Mar 2015 15:27:06 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Sun, 1 Mar 2015 15:27:06 -0500
In 6f9bd50eabb0a4960e94c83dac8855771c9f340d, we modified
expand_security_quals() to tell expand_security_qual() about when the
current RTE was the targetRelation. Unfortunately, that commit
initialized the targetRelation variable used outside of the loop over
the RTEs instead of at the start of it.
This patch moves the variable and the initialization of it into the
loop, where it should have been to begin with.
Pointed out by Dean Rasheed.
Back-patch to 9.4 as the original commit was.
M src/backend/optimizer/prep/prepsecurity.c
Unlink static libraries before rebuilding them.
commit : 22dd465d34f55b5a5b1790a5b5582fef9558d84b
author : Noah Misch <noah@leadboat.com>
date : Sun, 1 Mar 2015 13:05:23 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sun, 1 Mar 2015 13:05:23 -0500
When the library already exists in the build directory, "ar" preserves
members not named on its command line. This mattered when, for example,
a "configure" rerun dropped a file from $(LIBOBJS). libpgport carried
the obsolete member until "make clean". Back-patch to 9.0 (all
supported versions).
M src/Makefile.shlib
M src/common/Makefile
M src/port/Makefile
Fix planning of star-schema-style queries.
commit : fdacbf9e89267a3c3eb382b285bdb724ad5c6e44
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 28 Feb 2015 12:43:04 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 28 Feb 2015 12:43:04 -0500
Part of the intent of the parameterized-path mechanism was to handle
star-schema queries efficiently, but some overly-restrictive search
limiting logic added in commit e2fa76d80ba571d4de8992de6386536867250474
prevented such cases from working as desired. Fix that and add a
regression test about it. Per gripe from Marc Cousin.
This is arguably a bug rather than a new feature, so back-patch to 9.2
where parameterized paths were introduced.
M src/backend/optimizer/README
M src/backend/optimizer/path/joinpath.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Suppress uninitialized-variable warning from less-bright compilers.
commit : 60ff5de22aa4781f60cc141e2518c242c66d9235
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 Feb 2015 18:19:22 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 Feb 2015 18:19:22 -0500
The type variable must get set on first iteration of the while loop,
but there are reasonably modern gcc versions that don't realize that.
Initialize it with a dummy value. This undoes a removal of initialization
in commit 654809e770ce270c0bb9de726c5df1ab193d60f0.
M src/backend/utils/adt/jsonb.c
Fix a couple of trivial issues in jsonb.c
commit : ecfe1a1889bc8640a4e3b8659d69ec1fd0e30b4a
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 27 Feb 2015 18:54:49 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 27 Feb 2015 18:54:49 -0300
Typo "aggreagate" appeared three times, and the return value of function
JsonbIteratorNext() was being assigned to an int variable in a bunch of
places.
M src/backend/utils/adt/jsonb.c
Render infinite date/timestamps as 'infinity' for json/jsonb
commit : 79afe6e66f022ea9cd6c34c334214b2fda870faa
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 26 Feb 2015 12:34:43 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 26 Feb 2015 12:34:43 -0500
Commit ab14a73a6c raised an error in these cases and later the
behaviour was copied to jsonb. This is what the XML code, which we
then adopted, does, as the XSD types don't accept infinite values.
However, json dates and timestamps are just strings as far as json is
concerned, so there is no reason not to render these values as
'infinity'.
The json portion of this is backpatched to 9.4 where the behaviour was
introduced. The jsonb portion only affects the development branch.
Per gripe on pgsql-general.
M src/backend/utils/adt/json.c
M src/test/regress/expected/json.out
M src/test/regress/expected/json_1.out
M src/test/regress/sql/json.sql
Reconsider when to wait for WAL flushes/syncrep during commit.
commit : d7211511270b14d992e1a064acff2d07045654e2
author : Andres Freund <andres@anarazel.de>
date : Thu, 26 Feb 2015 12:50:07 +0100
committer: Andres Freund <andres@anarazel.de>
date : Thu, 26 Feb 2015 12:50:07 +0100
Up to now RecordTransactionCommit() waited for WAL to be flushed (if
synchronous_commit != off) and to be synchronously replicated (if
enabled), even if a transaction did not have a xid assigned. The primary
reason for that is that sequence's nextval() did not assign a xid, but
are worthwhile to wait for on commit.
This can be problematic because sometimes read only transactions do
write WAL, e.g. HOT page prune records. That then could lead to read only
transactions having to wait during commit. Not something people expect
in a read only transaction.
This lead to such strange symptoms as backends being seemingly stuck
during connection establishment when all synchronous replicas are
down. Especially annoying when said stuck connection is the standby
trying to reconnect to allow syncrep again...
This behavior also is involved in a rather complicated <= 9.4 bug where
the transaction started by catchup interrupt processing waited for
syncrep using latches, but didn't get the wakeup because it was already
running inside the same overloaded signal handler. Fix the issue here
doesn't properly solve that issue, merely papers over the problems. In
9.5 catchup interrupts aren't processed out of signal handlers anymore.
To fix all this, make nextval() acquire a top level xid, and only wait for
transaction commit if a transaction both acquired a xid and emitted WAL
records. If only a xid has been assigned we don't uselessly want to
wait just because of writes to temporary/unlogged tables; if only WAL
has been written we don't want to wait just because of HOT prunes.
The xid assignment in nextval() is unlikely to cause overhead in
real-world workloads. For one it only happens SEQ_LOG_VALS/32 values
anyway, for another only usage of nextval() without using the result in
an insert or similar is affected.
Discussion: 20150223165359.GF30784@awork2.anarazel.de,
369698E947874884A77849D8FE3680C2@maumau,
5CF4ABBA67674088B3941894E22A0D25@maumau
Per complaint from maumau and Thom Brown
Backpatch all the way back; 9.0 doesn't have syncrep, but it seems
better to be consistent behavior across all maintained branches.
M src/backend/access/transam/xact.c
M src/backend/commands/sequence.c
Free SQLSTATE and SQLERRM no earlier than other PL/pgSQL variables.
commit : 38930e473a799c1ba2b33b2964dd2b9f8862a268
author : Noah Misch <noah@leadboat.com>
date : Wed, 25 Feb 2015 23:48:28 -0500
committer: Noah Misch <noah@leadboat.com>
date : Wed, 25 Feb 2015 23:48:28 -0500
"RETURN SQLERRM" prompted plpgsql_exec_function() to read from freed
memory. Back-patch to 9.0 (all supported versions). Little code ran
between the premature free and the read, so non-assert builds are
unlikely to witness user-visible consequences.
M src/pl/plpgsql/src/pl_exec.c
M src/test/regress/expected/plpgsql.out
M src/test/regress/sql/plpgsql.sql
Add locking clause for SB views for update/delete
commit : f16270aded0af5f3b19719bee3f67c8cc19b20aa
author : Stephen Frost <sfrost@snowman.net>
date : Wed, 25 Feb 2015 21:36:40 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Wed, 25 Feb 2015 21:36:40 -0500
In expand_security_qual(), we were handling locking correctly when a
PlanRowMark existed, but not when we were working with the target
relation (which doesn't have any PlanRowMarks, but the subquery created
for the security barrier quals still needs to lock the rows under it).
Noted by Etsuro Fujita when working with the Postgres FDW, which wasn't
properly issuing a SELECT ... FOR UPDATE to the remote side under a
DELETE.
Back-patch to 9.4 where updatable security barrier views were
introduced.
Per discussion with Etsuro and Dean Rasheed.
M src/backend/optimizer/prep/prepsecurity.c
M src/test/regress/expected/updatable_views.out
Fix dumping of views that are just VALUES(...) but have column aliases.
commit : 2164a0de2929e39ffc462eb1e19d71f93621fdf1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 25 Feb 2015 12:01:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 25 Feb 2015 12:01:12 -0500
The "simple" path for printing VALUES clauses doesn't work if we need
to attach nondefault column aliases, because there's noplace to do that
in the minimal VALUES() syntax. So modify get_simple_values_rte() to
detect nondefault aliases and treat that as a non-simple case. This
further exposes that the "non-simple" path never actually worked;
it didn't produce valid syntax. Fix that too. Per bug #12789 from
Curtis McEnroe, and analysis by Andrew Gierth.
Back-patch to all supported branches. Before 9.3, this also requires
back-patching the part of commit 092d7ded29f36b0539046b23b81b9f0bf2d637f1
that created get_simple_values_rte() to begin with; inserting the extra
test into the old factorization of that logic would've been too messy.
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql
Guard against spurious signals in LockBufferForCleanup.
commit : 89629f28959b877c678e6cccce243b0a00d307f8
author : Andres Freund <andres@anarazel.de>
date : Mon, 23 Feb 2015 16:11:11 +0100
committer: Andres Freund <andres@anarazel.de>
date : Mon, 23 Feb 2015 16:11:11 +0100
When LockBufferForCleanup() has to wait for getting a cleanup lock on a
buffer it does so by setting a flag in the buffer header and then wait
for other backends to signal it using ProcWaitForSignal().
Unfortunately LockBufferForCleanup() missed that ProcWaitForSignal() can
return for other reasons than the signal it is hoping for. If such a
spurious signal arrives the wait flags on the buffer header will still
be set. That then triggers "ERROR: multiple backends attempting to wait
for pincount 1".
The fix is simple, unset the flag if still set when retrying. That
implies an additional spinlock acquisition/release, but that's unlikely
to matter given the cost of waiting for a cleanup lock. Alternatively
it'd have been possible to move responsibility for maintaining the
relevant flag to the waiter all together, but that might have had
negative consequences due to possible floods of signals. Besides being
more invasive.
This looks to be a very longstanding bug. The relevant code in
LockBufferForCleanup() hasn't changed materially since its introduction
and ProcWaitForSignal() was documented to return for unrelated reasons
since 8.2. The master only patch series removing ImmediateInterruptOK
made it much easier to hit though, as ProcSendSignal/ProcWaitForSignal
now uses a latch shared with other tasks.
Per discussion with Kevin Grittner, Tom Lane and me.
Backpatch to all supported branches.
Discussion: 11553.1423805224@sss.pgh.pa.us
M src/backend/storage/buffer/bufmgr.c
Fix potential deadlock with libpq non-blocking mode.
commit : 0214a61e062f7d23d28e423850c20fc287d3f5e5
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 23 Feb 2015 13:32:34 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 23 Feb 2015 13:32:34 +0200
If libpq output buffer is full, pqSendSome() function tries to drain any
incoming data. This avoids deadlock, if the server e.g. sends a lot of
NOTICE messages, and blocks until we read them. However, pqSendSome() only
did that in blocking mode. In non-blocking mode, the deadlock could still
happen.
To fix, take a two-pronged approach:
1. Change the documentation to instruct that when PQflush() returns 1, you
should wait for both read- and write-ready, and call PQconsumeInput() if it
becomes read-ready. That fixes the deadlock, but applications are not going
to change overnight.
2. In pqSendSome(), drain the input buffer before returning 1. This
alleviates the problem for applications that only wait for write-ready. In
particular, a slow but steady stream of NOTICE messages during COPY FROM
STDIN will no longer cause a deadlock. The risk remains that the server
attempts to send a large burst of data and fills its output buffer, and at
the same time the client also sends enough data to fill its output buffer.
The application will deadlock if it goes to sleep, waiting for the socket
to become write-ready, before the server's data arrives. In practice,
NOTICE messages and such that the server might be sending are usually
short, so it's highly unlikely that the server would fill its output buffer
so quickly.
Backpatch to all supported versions.
M doc/src/sgml/libpq.sgml
M src/interfaces/libpq/fe-misc.c
Fix misparsing of empty value in conninfo_uri_parse_params().
commit : 9c15a778a03d009883ec4370ac8b8d30d279aaa7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Feb 2015 12:59:25 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Feb 2015 12:59:25 -0500
After finding an "=" character, the pointer was advanced twice when it
should only advance once. This is harmless as long as the value after "="
has at least one character; but if it doesn't, we'd miss the terminator
character and include too much in the value.
In principle this could lead to reading off the end of memory. It does not
seem worth treating as a security issue though, because it would happen on
client side, and besides client logic that's taking conninfo strings from
untrusted sources has much worse security problems than this.
Report and patch received off-list from Thomas Fanghaenel.
Back-patch to 9.2 where the faulty code was introduced.
M src/interfaces/libpq/fe-connect.c
Fix object identities for pg_conversion objects
commit : 66463a3cf1a567628be29fc9084c4ff51df772cf
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 Feb 2015 14:28:12 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 Feb 2015 14:28:12 -0300
We were neglecting to schema-qualify them.
Backpatch to 9.3, where object identities were introduced as a concept
by commit f8348ea32ec8.
M src/backend/catalog/objectaddress.c
Fix failure to honor -Z compression level option in pg_dump -Fd.
commit : a75dfb73e19e2da5ac0bd9a0c616c42a2a2b5ad1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 18 Feb 2015 11:43:00 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 18 Feb 2015 11:43:00 -0500
cfopen() and cfopen_write() failed to pass the compression level through
to zlib, so that you always got the default compression level if you got
any at all.
In passing, also fix these and related functions so that the correct errno
is reliably returned on failure; the original coding supposes that free()
cannot change errno, which is untrue on at least some platforms.
Per bug #12779 from Christoph Berg. Back-patch to 9.1 where the faulty
code was introduced.
Michael Paquier
M src/bin/pg_dump/compress_io.c
Remove code to match IPv4 pg_hba.conf entries to IPv4-in-IPv6 addresses.
commit : a271c9260fa4a12007083a4343cf27ac1309ef0d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Feb 2015 12:49:18 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Feb 2015 12:49:18 -0500
In investigating yesterday's crash report from Hugo Osvaldo Barrera, I only
looked back as far as commit f3aec2c7f51904e7 where the breakage occurred
(which is why I thought the IPv4-in-IPv6 business was undocumented). But
actually the logic dates back to commit 3c9bb8886df7d56a and was simply
broken by erroneous refactoring in the later commit. A bit of archives
excavation shows that we added the whole business in response to a report
that some 2003-era Linux kernels would report IPv4 connections as having
IPv4-in-IPv6 addresses. The fact that we've had no complaints since 9.0
seems to be sufficient confirmation that no modern kernels do that, so
let's just rip it all out rather than trying to fix it.
Do this in the back branches too, thus essentially deciding that our
effective behavior since 9.0 is correct. If there are any platforms on
which the kernel reports IPv4-in-IPv6 addresses as such, yesterday's fix
would have made for a subtle and potentially security-sensitive change in
the effective meaning of IPv4 pg_hba.conf entries, which does not seem like
a good thing to do in minor releases. So let's let the post-9.0 behavior
stand, and change the documentation to match it.
In passing, I failed to resist the temptation to wordsmith the description
of pg_hba.conf IPv4 and IPv6 address entries a bit. A lot of this text
hasn't been touched since we were IPv4-only.
M doc/src/sgml/client-auth.sgml
M src/backend/libpq/hba.c
M src/backend/libpq/ip.c
M src/include/libpq/ip.h
Improve pg_check_dir code and comments.
commit : 5e49c98e0a9949e6f86b068837ca59c36d8619ba
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 17 Feb 2015 10:19:30 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 17 Feb 2015 10:19:30 -0500
Avoid losing errno if readdir() fails and closedir() works. Consistently
return 4 rather than 3 if both a lost+found directory and other files are
found, rather than returning one value or the other depending on the
order of the directory listing. Update comments to match the actual
behavior.
These oversights date to commits 6f03927fce038096f53ca67eeab9adb24938f8a6
and 17f15239325a88581bb4f9cf91d38005f1f52d69.
Marco Nenciarini
M src/port/pgcheckdir.c
Fix misuse of memcpy() in check_ip().
commit : 23291a796fdeeb3ba6f28b336cebef5f98c1dcce
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 16 Feb 2015 16:17:48 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 16 Feb 2015 16:17:48 -0500
The previous coding copied garbage into a local variable, pretty much
ensuring that the intended test of an IPv6 connection address against a
promoted IPv4 address from pg_hba.conf would never match. The lack of
field complaints likely indicates that nobody realized this was supposed
to work, which is unsurprising considering that no user-facing docs suggest
it should work.
In principle this could have led to a SIGSEGV due to reading off the end of
memory, but since the source address would have pointed to somewhere in the
function's stack frame, that's quite unlikely. What led to discovery of
the bug is Hugo Osvaldo Barrera's report of a crash after an OS upgrade,
which is probably because he is now running a system in which memcpy raises
abort() upon detecting overlapping source and destination areas. (You'd
have to additionally suppose some things about the stack frame layout to
arrive at this conclusion, but it seems plausible.)
This has been broken since the code was added, in commit f3aec2c7f51904e7,
so back-patch to all supported branches.
M src/backend/libpq/hba.c
Fix null-pointer-deref crash while doing COPY IN with check constraints.
commit : 1bf32972e6daf91329ceacca80e5ba67068882bb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Feb 2015 23:26:45 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Feb 2015 23:26:45 -0500
In commit bf7ca15875988a88e97302e012d7c4808bef3ea9 I introduced an
assumption that an RTE referenced by a whole-row Var must have a valid eref
field. This is false for RTEs constructed by DoCopy, and there are other
places taking similar shortcuts. Perhaps we should make all those places
go through addRangeTableEntryForRelation or its siblings instead of having
ad-hoc logic, but the most reliable fix seems to be to make the new code in
ExecEvalWholeRowVar cope if there's no eref. We can reasonably assume that
there's no need to insert column aliases if no aliases were provided.
Add a regression test case covering this, and also verifying that a sane
column name is in fact available in this situation.
Although the known case only crashes in 9.4 and HEAD, it seems prudent to
back-patch the code change to 9.2, since all the ingredients for a similar
failure exist in the variant patch applied to 9.3 and 9.2.
Per report from Jean-Pierre Pelletier.
M src/backend/executor/execQual.c
M src/test/regress/expected/copy2.out
M src/test/regress/sql/copy2.sql
pg_regress: Write processed input/*.source into output dir
commit : 9a165aa0b40d47e32b69d03ca6980647dfa76b4e
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 14 Feb 2015 21:33:41 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 14 Feb 2015 21:33:41 -0500
Before, it was writing the processed files into the input directory,
which is incorrect in a vpath build.
M src/test/regress/pg_regress.c
Fix broken #ifdef for __sparcv8
commit : 56a23a83fd310413e26f022b68b457dae82a9de0
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 13 Feb 2015 23:51:23 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 13 Feb 2015 23:51:23 +0200
Rob Rowan. Backpatch to all supported versions, like the patch that added
the broken #ifdef.
M src/include/storage/s_lock.h
pg_upgrade: quote directory names in delete_old_cluster script
commit : 5eef3c61ecf9cbd24116252cb9d3ccdf6c3f38fc
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 11 Feb 2015 22:06:04 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 11 Feb 2015 22:06:04 -0500
This allows the delete script to properly function when special
characters appear in directory paths, e.g. spaces.
Backpatch through 9.0
M contrib/pg_upgrade/check.c
pg_upgrade: preserve freeze info for postgres/template1 dbs
commit : c7bc5be11de9ed9e4b9ee6c06e65fee314bab7e0
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 11 Feb 2015 21:02:07 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 11 Feb 2015 21:02:07 -0500
pg_database.datfrozenxid and pg_database.datminmxid were not preserved
for the 'postgres' and 'template1' databases. This could cause missing
clog file errors on access to user tables and indexes after upgrades in
these databases.
Backpatch through 9.0
M src/bin/pg_dump/pg_dumpall.c
Fix typo in logicaldecoding.sgml.
commit : 9dd56460ccd7a54e8b70c05995b6aa19a7126e6a
author : Andres Freund <andres@anarazel.de>
date : Thu, 12 Feb 2015 01:16:32 +0100
committer: Andres Freund <andres@anarazel.de>
date : Thu, 12 Feb 2015 01:16:32 +0100
Author: Tatsuo Ishii
Backpatch to 9.4, where logicaldecoding was introduced.
M doc/src/sgml/logicaldecoding.sgml
Fix missing PQclear() in libpqrcv_endstreaming().
commit : 0ac1fedab9e87756d13b22117f29fe4c5212da75
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Feb 2015 19:20:49 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Feb 2015 19:20:49 -0500
This omission leaked one PGresult per WAL streaming cycle, which possibly
would never be enough to notice in the real world, but it's still a leak.
Per Coverity. Back-patch to 9.3 where the error was introduced.
M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
Fix minor memory leak in ident_inet().
commit : e44735c48821e40b2679d5b69c4d47e98ddaae6f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Feb 2015 19:09:54 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Feb 2015 19:09:54 -0500
We'd leak the ident_serv data structure if the second pg_getaddrinfo_all
(the one for the local address) failed. This is not of great consequence
because a failure return here just leads directly to backend exit(), but
if this function is going to try to clean up after itself at all, it should
not have such holes in the logic. Try to fix it in a future-proof way by
having all the failure exits go through the same cleanup path, rather than
"optimizing" some of them.
Per Coverity. Back-patch to 9.2, which is as far back as this patch
applies cleanly.
M src/backend/libpq/auth.c
Fix more memory leaks in failure path in buildACLCommands.
commit : ee8d3778311e08d810f79c97f90ffb678063a59f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Feb 2015 18:35:23 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Feb 2015 18:35:23 -0500
We already had one go at this issue in commit d73b7f973db5ec7e, but we
failed to notice that buildACLCommands also leaked several PQExpBuffers
along with a simply malloc'd string. This time let's try to make the
fix a bit more future-proof by eliminating the separate exit path.
It's still not exactly critical because pg_dump will curl up and die on
failure; but since the amount of the potential leak is now several KB,
it seems worth back-patching as far as 9.2 where the previous fix landed.
Per Coverity, which evidently is smarter than clang's static analyzer.
M src/bin/pg_dump/dumputils.c
Fixed array handling in ecpg.
commit : 66c4ea8cb6e8d282111783326e5c9bec330bf4e2
author : Michael Meskes <meskes@postgresql.org>
date : Wed, 11 Feb 2015 10:45:46 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Wed, 11 Feb 2015 10:45:46 +0100
When ecpg was rewritten to the new protocol version not all variable types
were corrected. This patch rewrites the code for these types to fix that. It
also fixes the documentation to correctly tell the status of array handling.
M doc/src/sgml/ecpg.sgml
M src/interfaces/ecpg/ecpglib/data.c
M src/interfaces/ecpg/ecpglib/execute.c
Fix pg_dump's heuristic for deciding which casts to dump.
commit : a592e5883529b7a73188d1b325c30a5a4eee65e4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Feb 2015 22:38:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Feb 2015 22:38:17 -0500
Back in 2003 we had a discussion about how to decide which casts to dump.
At the time pg_dump really only considered an object's containing schema
to decide what to dump (ie, dump whatever's not in pg_catalog), and so
we chose a complicated idea involving whether the underlying types were to
be dumped (cf commit a6790ce85752b67ad994f55fdf1a450262ccc32e). But users
are allowed to create casts between built-in types, and we failed to dump
such casts. Let's get rid of that heuristic, which has accreted even more
ugliness since then, in favor of just looking at the cast's OID to decide
if it's a built-in cast or not.
In passing, also fix some really ancient code that supposed that it had to
manufacture a dependency for the cast on its cast function; that's only
true when dumping from a pre-7.3 server. This just resulted in some wasted
cycles and duplicate dependency-list entries with newer servers, but we
might as well improve it.
Per gripes from a number of people, most recently Greg Sabino Mullane.
Back-patch to all supported branches.
M src/bin/pg_dump/pg_dump.c
Fix GEQO to not assume its join order heuristic always works.
commit : 433c79d2c88009e4f4a053bc4e32a18719136611
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Feb 2015 20:37:22 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Feb 2015 20:37:22 -0500
Back in commit 400e2c934457bef4bc3cc9a3e49b6289bd761bc0 I rewrote GEQO's
gimme_tree function to improve its heuristic for modifying the given tour
into a legal join order. In what can only be called a fit of hubris,
I supposed that this new heuristic would *always* find a legal join order,
and ripped out the old logic that allowed gimme_tree to sometimes fail.
The folly of this is exposed by bug #12760, in which the "greedy" clumping
behavior of merge_clump() can lead it into a dead end which could only be
recovered from by un-clumping. We have no code for that and wouldn't know
exactly what to do with it if we did. Rather than try to improve the
heuristic rules still further, let's just recognize that it *is* a
heuristic and probably must always have failure cases. So, put back the
code removed in the previous commit to allow for failure (but comment it
a bit better this time).
It's possible that this code was actually fully correct at the time and
has only been broken by the introduction of LATERAL. But having seen this
example I no longer have much faith in that proposition, so back-patch to
all supported branches.
M src/backend/optimizer/geqo/geqo_eval.c
M src/backend/optimizer/geqo/geqo_main.c
M src/backend/optimizer/geqo/geqo_pool.c
Minor cleanup/code review for "indirect toast" stuff.
commit : ccf655c446d9b2de98455cf29f27795e0e067779
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Feb 2015 12:30:55 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Feb 2015 12:30:55 -0500
Fix some issues I noticed while fooling with an extension to allow an
additional kind of toast pointer. Much of this is just comment
improvement, but there are a couple of actual bugs, which might or might
not be reachable today depending on what can happen during logical
decoding. An example is that toast_flatten_tuple() failed to cover the
possibility of an indirection pointer in its input. Back-patch to 9.4
just in case that is reachable now.
In HEAD, also correct some really minor issues with recent compression
reorganization, such as dangerously underparenthesized macros.
M src/backend/access/heap/tuptoaster.c
M src/include/access/tuptoaster.h
M src/include/postgres.h
Report WAL flush, not insert, position in replication IDENTIFY_SYSTEM
commit : 3bc4c694271bfe28b909f43d45fe5168c18ad5b8
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 6 Feb 2015 11:18:14 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 6 Feb 2015 11:18:14 +0200
When beginning streaming replication, the client usually issues the
IDENTIFY_SYSTEM command, which used to return the current WAL insert
position. That's not suitable for the intended purpose of that field,
however. pg_receivexlog uses it to start replication from the reported
point, but if it hasn't been flushed to disk yet, it will fail. Change
IDENTIFY_SYSTEM to report the flush position instead.
Backpatch to 9.1 and above. 9.0 doesn't report any WAL position.
M doc/src/sgml/protocol.sgml
M src/backend/replication/walsender.c
Fix reference-after-free when waiting for another xact due to constraint.
commit : 48a565d78ba9413317d6095010cf622e9d6a36eb
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 4 Feb 2015 16:00:34 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 4 Feb 2015 16:00:34 +0200
If an insertion or update had to wait for another transaction to finish,
because there was another insertion with conflicting key in progress,
we would pass a just-free'd item pointer to XactLockTableWait().
All calls to XactLockTableWait() and MultiXactIdWait() had similar issues.
Some passed a pointer to a buffer in the buffer cache, after already
releasing the lock. The call in EvalPlanQualFetch had already released the
pin too. All but the call in execUtils.c would merely lead to reporting a
bogus ctid, however (or an assertion failure, if enabled).
All the callers that passed HeapTuple->t_data->t_ctid were slightly bogus
anyway: if the tuple was updated (again) in the same transaction, its ctid
field would point to the next tuple in the chain, not the tuple itself.
Backpatch to 9.4, where the 'ctid' argument to XactLockTableWait was added
(in commit f88d4cfc)
M src/backend/access/heap/heapam.c
M src/backend/catalog/index.c
M src/backend/executor/execMain.c
M src/backend/executor/execUtils.c
Add missing float.h include to snprintf.c.
commit : 742734d2b54005f228655f0733e869b16ec6cb2b
author : Andres Freund <andres@anarazel.de>
date : Wed, 4 Feb 2015 13:27:31 +0100
committer: Andres Freund <andres@anarazel.de>
date : Wed, 4 Feb 2015 13:27:31 +0100
On windows _isnan() (which isnan() is redirected to in port/win32.h)
is declared in float.h, not math.h.
Per buildfarm animal currawong.
Backpatch to all supported branches.
M src/port/snprintf.c
doc: Fix markup
commit : 7c21a8aca39c504ea448cce82230163ca93cfaf4
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 4 Feb 2015 19:00:09 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 4 Feb 2015 19:00:09 +0900
Ian Barwick
M doc/src/sgml/logicaldecoding.sgml
M doc/src/sgml/ref/create_tablespace.sgml
Fix breakage in GEODEBUG debug code.
commit : 900679245de9d7f407dc72c34a5beb4124955f6f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 3 Feb 2015 15:20:48 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 3 Feb 2015 15:20:48 -0500
LINE doesn't have an "m" field (anymore anyway). Also fix unportable
assumption that %x can print the result of pointer subtraction.
In passing, improve single_decode() in minor ways:
* Remove unnecessary leading-whitespace skip (strtod does that already).
* Make GEODEBUG message more intelligible.
* Remove entirely-useless test to see if strtod returned a silly pointer.
* Don't bother computing trailing-whitespace skip unless caller wants
an ending pointer.
This has been broken since 261c7d4b653bc3e44c31fd456d94f292caa50d8f.
Although it's only debug code, might as well fix the 9.4 branch too.
M src/backend/utils/adt/geo_ops.c