Stamp 9.3.2.
commit : 05ec931add20f201e579e960b18c1cf770da6ee3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Dec 2013 15:57:48 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Dec 2013 15:57:48 -0500
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
Update release notes for 9.3.2, 9.2.6, 9.1.11, 9.0.15, 8.4.19.
commit : 9cb631d98443b64a6ac8f5d14ffb95a45a9adad4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Dec 2013 15:53:58 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Dec 2013 15:53:58 -0500
M doc/src/sgml/release-8.4.sgml
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
Translation updates
commit : 8d1c2981f0c6a0a74a4759004ea1cfb0193cfea4
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 2 Dec 2013 00:09:43 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 2 Dec 2013 00:09:43 -0500
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/bin/initdb/po/cs.po
M src/bin/pg_basebackup/po/cs.po
M src/bin/pg_basebackup/po/zh_CN.po
M src/bin/pg_config/po/cs.po
M src/bin/pg_controldata/po/cs.po
M src/bin/pg_ctl/po/cs.po
M src/bin/pg_dump/po/cs.po
M src/bin/pg_resetxlog/po/cs.po
M src/bin/psql/po/cs.po
M src/bin/scripts/po/cs.po
M src/interfaces/ecpg/ecpglib/po/cs.po
M src/interfaces/ecpg/preproc/po/cs.po
M src/interfaces/libpq/po/cs.po
M src/pl/plperl/po/cs.po
M src/pl/plpgsql/src/po/cs.po
M src/pl/plpython/po/cs.po
M src/pl/tcl/po/cs.po
Update time zone data files to tzdata release 2013h.
commit : 4e213be863daf0ae1fdefd3464d40a8f492a8740
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 1 Dec 2013 14:11:44 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 1 Dec 2013 14:11:44 -0500
DST law changes in Argentina, Brazil, Jordan, Libya, Liechtenstein,
Morocco, Palestine. New timezone abbreviations WIB, WIT, WITA for
Indonesia.
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/etcetera
M src/timezone/data/europe
M src/timezone/data/iso3166.tab
M src/timezone/data/leapseconds
M src/timezone/data/northamerica
M src/timezone/data/southamerica
M src/timezone/data/zone.tab
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/Asia.txt
Fix pg_dumpall to work for databases flagged as read-only.
commit : 53b0f213448905c70b629364c318da316005208d
author : Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 30 Nov 2013 11:33:04 -0600
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 30 Nov 2013 11:33:04 -0600
pg_dumpall's charter is to be able to recreate a database cluster's
contents in a virgin installation, but it was failing to honor that
contract if the cluster had any ALTER DATABASE SET
default_transaction_read_only settings. By including a SET command
for the connection for each connection opened by pg_dumpall output,
errors are avoided and the source cluster is successfully
recreated.
There was discussion of whether to also set this for the connection
applying pg_dump output, but it was felt that it was both less
appropriate in that context, and far easier to work around.
Backpatch to all supported branches.
M src/bin/pg_dump/pg_dumpall.c
Fix a couple of bugs in MultiXactId freezing
commit : 8e53ae025de90b8f7d935ce0eb4d0551178a4caf
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 28 Nov 2013 19:17:21 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 28 Nov 2013 19:17:21 -0300
Both heap_freeze_tuple() and heap_tuple_needs_freeze() neglected to look
into a multixact to check the members against cutoff_xid. This means
that a very old Xid could survive hidden within a multi, possibly
outliving its CLOG storage. In the distant future, this would cause
clog lookup failures:
ERROR: could not access status of transaction 3883960912
DETAIL: Could not open file "pg_clog/0E78": No such file or directory.
This mostly was problematic when the updating transaction aborted, since
in that case the row wouldn't get pruned away earlier in vacuum and the
multixact could possibly survive for a long time. In many cases, data
that is inaccessible for this reason way can be brought back
heuristically.
As a second bug, heap_freeze_tuple() didn't properly handle multixacts
that need to be frozen according to cutoff_multi, but whose updater xid
is still alive. Instead of preserving the update Xid, it just set Xmax
invalid, which leads to both old and new tuple versions becoming
visible. This is pretty rare in practice, but a real threat
nonetheless. Existing corrupted rows, unfortunately, cannot be repaired
in an automated fashion.
Existing physical replicas might have already incorrectly frozen tuples
because of different behavior than in master, which might only become
apparent in the future once pg_multixact/ is truncated; it is
recommended that all clones be rebuilt after upgrading.
Following code analysis caused by bug report by J Smith in message
CADFUPgc5bmtv-yg9znxV-vcfkb+JPRqs7m2OesQXaM_4Z1JpdQ@mail.gmail.com
and privately by F-Secure.
Backpatch to 9.3, where freezing of MultiXactIds was introduced.
Analysis and patch by Andres Freund, with some tweaks by Álvaro.
M src/backend/access/heap/heapam.c
M src/backend/access/transam/multixact.c
Don't TransactionIdDidAbort in HeapTupleGetUpdateXid
commit : 663d2e485e4d526770ab618469d875c404714119
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 29 Nov 2013 16:08:06 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 29 Nov 2013 16:08:06 -0300
It is dangerous to do so, because some code expects to be able to see what's
the true Xmax even if it is aborted (particularly while traversing HOT
chains). So don't do it, and instead rely on the callers to verify for
abortedness, if necessary.
Several race conditions and bugs fixed in the process. One isolation test
changes the expected output due to these.
This also reverts commit c235a6a589b, which is no longer necessary.
Backpatch to 9.3, where this function was introduced.
Andres Freund
M src/backend/access/heap/heapam.c
M src/backend/access/heap/pruneheap.c
M src/backend/utils/time/tqual.c
M src/test/isolation/expected/delete-abort-savept.out
Truncate pg_multixact/'s contents during crash recovery
commit : 215ac4ad6589e0f6a31cc4cd867aedba3cd42924
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 29 Nov 2013 11:26:41 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 29 Nov 2013 11:26:41 -0300
Commit 9dc842f08 of 8.2 era prevented MultiXact truncation during crash
recovery, because there was no guarantee that enough state had been
setup, and because it wasn't deemed to be a good idea to remove data
during crash recovery anyway. Since then, due to Hot-Standby, streaming
replication and PITR, the amount of time a cluster can spend doing crash
recovery has increased significantly, to the point that a cluster may
even never come out of it. This has made not truncating the content of
pg_multixact/ not defensible anymore.
To fix, take care to setup enough state for multixact truncation before
crash recovery starts (easy since checkpoints contain the required
information), and move the current end-of-recovery actions to a new
TrimMultiXact() function, analogous to TrimCLOG().
At some later point, this should probably done similarly to the way
clog.c is doing it, which is to just WAL log truncations, but we can't
do that for the back branches.
Back-patch to 9.0. 8.4 also has the problem, but since there's no hot
standby there, it's much less pressing. In 9.2 and earlier, this patch
is simpler than in newer branches, because multixact access during
recovery isn't required. Add appropriate checks to make sure that's not
happening.
Andres Freund
M src/backend/access/transam/multixact.c
M src/backend/access/transam/xlog.c
M src/include/access/multixact.h
Fix full-table-vacuum request mechanism for MultiXactIds
commit : f5f92bdc44ffdf577244e0d055825cacd0cdea10
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 28 Nov 2013 16:52:54 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 28 Nov 2013 16:52:54 -0300
While autovacuum dutifully launched anti-multixact-wraparound vacuums
when the multixact "age" was reached, the vacuum code was not aware that
it needed to make them be full table vacuums. As the resulting
partial-table vacuums aren't capable of actually increasing relminmxid,
autovacuum continued to launch anti-wraparound vacuums that didn't have
the intended effect, until age of relfrozenxid caused the vacuum to
finally be a full table one via vacuum_freeze_table_age.
To fix, introduce logic for multixacts similar to that for plain
TransactionIds, using the same GUCs.
Backpatch to 9.3, where permanent MultiXactIds were introduced.
Andres Freund, some cleanup by Álvaro
M src/backend/access/transam/multixact.c
M src/backend/commands/cluster.c
M src/backend/commands/vacuum.c
M src/backend/commands/vacuumlazy.c
M src/include/access/multixact.h
M src/include/commands/vacuum.h
Replace hardcoded 200000000 with autovacuum_freeze_max_age
commit : d9484ab5f3cbcfea64536fec333723f9aa4c0b2c
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 28 Nov 2013 16:45:29 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 28 Nov 2013 16:45:29 -0300
Parts of the code used autovacuum_freeze_max_age to determine whether
anti-multixact-wraparound vacuums are necessary, while others used a
hardcoded 200000000 value. This leads to problems when
autovacuum_freeze_max_age is set to a non-default value. Use the latter
everywhere.
Backpatch to 9.3, where vacuuming of multixacts was introduced.
Andres Freund
M src/backend/access/transam/multixact.c
Fix assorted issues in pg_ctl's pgwin32_CommandLine().
commit : a9380b5c333043fc1ffc342475b3b1f2c021e962
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Nov 2013 18:34:11 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Nov 2013 18:34:11 -0500
Ensure that the invocation command for postgres or pg_ctl runservice
double-quotes the executable's pathname; failure to do this leads to
trouble when the path contains spaces.
Also, ensure that the path ends in ".exe" in both cases and uses
backslashes rather than slashes as directory separators. The latter issue
is reported to confuse some third-party tools such as Symantec Backup Exec.
Also, rewrite the function to avoid buffer overrun issues by using a
PQExpBuffer instead of a fixed-size static buffer. Combinations of
very long executable pathnames and very long data directory pathnames
could have caused trouble before, for example.
Back-patch to all active branches, since this code has been like this
for a long while.
Naoya Anzai and Tom Lane, reviewed by Rajeev Rastogi
M src/bin/pg_ctl/pg_ctl.c
Be sure to release proc->backendLock after SetupLockInTable() failure.
commit : 360abc0a5be64b01050a9d7144158890236487b5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Nov 2013 17:35:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Nov 2013 17:35:12 -0500
The various places that transferred fast-path locks to the main lock table
neglected to release the PGPROC's backendLock if SetupLockInTable failed
due to being out of shared memory. In most cases this is no big deal since
ensuing error cleanup would release all held LWLocks anyway. But there are
some hot-standby functions that don't consider failure of
FastPathTransferRelationLocks to be a hard error, and in those cases this
oversight could lead to system lockup. For consistency, make all of these
places look the same as FastPathTransferRelationLocks.
Noted while looking for the cause of Dan Wood's bugs --- this wasn't it,
but it's a bug anyway.
M src/backend/storage/lmgr/lock.c
Fix assorted race conditions in the new timeout infrastructure.
commit : c357be2cd9434c70904d871d9b96828b31a50cc5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Nov 2013 16:41:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Nov 2013 16:41:03 -0500
Prevent handle_sig_alarm from losing control partway through due to a query
cancel (either an asynchronous SIGINT, or a cancel triggered by one of the
timeout handler functions). That would at least result in failure to
schedule any required future interrupt, and might result in actual
corruption of timeout.c's data structures, if the interrupt happened while
we were updating those.
We could still lose control if an asynchronous SIGINT arrives just as the
function is entered. This wouldn't break any data structures, but it would
have the same effect as if the SIGALRM interrupt had been silently lost:
we'd not fire any currently-due handlers, nor schedule any new interrupt.
To forestall that scenario, forcibly reschedule any pending timer interrupt
during AbortTransaction and AbortSubTransaction. We can avoid any extra
kernel call in most cases by not doing that until we've allowed
LockErrorCleanup to kill the DEADLOCK_TIMEOUT and LOCK_TIMEOUT events.
Another hazard is that some platforms (at least Linux and *BSD) block a
signal before calling its handler and then unblock it on return. When we
longjmp out of the handler, the unblock doesn't happen, and the signal is
left blocked indefinitely. Again, we can fix that by forcibly unblocking
signals during AbortTransaction and AbortSubTransaction.
These latter two problems do not manifest when the longjmp reaches
postgres.c, because the error recovery code there kills all pending timeout
events anyway, and it uses sigsetjmp(..., 1) so that the appropriate signal
mask is restored. So errors thrown outside any transaction should be OK
already, and cleaning up in AbortTransaction and AbortSubTransaction should
be enough to fix these issues. (We're assuming that any code that catches
a query cancel error and doesn't re-throw it will do at least a
subtransaction abort to clean up; but that was pretty much required already
by other subsystems.)
Lastly, ProcSleep should not clear the LOCK_TIMEOUT indicator flag when
disabling that event: if a lock timeout interrupt happened after the lock
was granted, the ensuing query cancel is still going to happen at the next
CHECK_FOR_INTERRUPTS, and we want to report it as a lock timeout not a user
cancel.
Per reports from Dan Wood.
Back-patch to 9.3 where the new timeout handling infrastructure was
introduced. We may at some point decide to back-patch the signal
unblocking changes further, but I'll desist from that until we hear
actual field complaints about it.
M src/backend/access/transam/xact.c
M src/backend/postmaster/autovacuum.c
M src/backend/storage/lmgr/proc.c
M src/backend/tcop/postgres.c
M src/backend/utils/misc/timeout.c
M src/include/utils/timeout.h
Fix latent(?) race condition in LockReleaseAll.
commit : 7747a76e211305099db1ff0483a13a50140af571
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 28 Nov 2013 12:17:49 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 28 Nov 2013 12:17:49 -0500
We have for a long time checked the head pointer of each of the backend's
proclock lists and skipped acquiring the corresponding locktable partition
lock if the head pointer was NULL. This was safe enough in the days when
proclock lists were changed only by the owning backend, but it is pretty
questionable now that the fast-path patch added cases where backends add
entries to other backends' proclock lists. However, we don't really wish
to revert to locking each partition lock every time, because in simple
transactions that would add a lot of useless lock/unlock cycles on
already-heavily-contended LWLocks. Fortunately, the only way that another
backend could be modifying our proclock list at this point would be if it
was promoting a formerly fast-path lock of ours; and any such lock must be
one that we'd decided not to delete in the previous loop over the locallock
table. So it's okay if we miss seeing it in this loop; we'd just decide
not to delete it again. However, once we've detected a non-empty list,
we'd better re-fetch the list head pointer after acquiring the partition
lock. This guards against possibly fetching a corrupt-but-non-null pointer
if pointer fetch/store isn't atomic. It's not clear if any practical
architectures are like that, but we've never assumed that before and don't
wish to start here. In any case, the situation certainly deserves a code
comment.
While at it, refactor the partition traversal loop to use a for() construct
instead of a while() loop with goto's.
Back-patch, just in case the risk is real and not hypothetical.
M src/backend/storage/lmgr/lock.c
Use a more granular approach to follow update chains
commit : 4c71f48f4c6c923d1b3f6e6c788e8a0995f4241a
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Nov 2013 17:50:33 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Nov 2013 17:50:33 -0300
Instead of simply checking the KEYS_UPDATED bit, we need to check
whether each lock held on the future version of the tuple conflicts with
the lock we're trying to acquire.
Per bug report #8434 by Tomonari Katsumata
M src/backend/access/heap/heapam.c
Compare Xmin to previous Xmax when locking an update chain
commit : 2a4b6eed0916a8fdc57b4778ecb1463fe752d369
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Nov 2013 17:49:12 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Nov 2013 17:49:12 -0300
Not doing so causes us to traverse an update chain that has been broken
by concurrent page pruning. All other code that traverses update chains
uses this check as one of the cases in which to stop iterating, so
replicate it here too. Failure to do so leads to erroneous CLOG,
subtrans or multixact lookups.
Per discussion following the bug report by J Smith in
CADFUPgc5bmtv-yg9znxV-vcfkb+JPRqs7m2OesQXaM_4Z1JpdQ@mail.gmail.com
as diagnosed by Andres Freund.
M src/backend/access/heap/heapam.c
Don't try to set InvalidXid as page pruning hint
commit : 4ed0640e5c356e0935c3a057de7361fc444c0056
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Nov 2013 17:47:16 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Nov 2013 17:47:16 -0300
If a transaction updates/deletes a tuple just before aborting, and a
concurrent transaction tries to prune the page concurrently, the pruner
may see HeapTupleSatisfiesVacuum return HEAPTUPLE_DELETE_IN_PROGRESS,
but a later call to HeapTupleGetUpdateXid() return InvalidXid. This
would cause an assertion failure in development builds, but would be
otherwise Mostly Harmless.
Fix by checking whether the updater Xid is valid before trying to apply
it as page prune point.
Reported by Andres in 20131124000203.GA4403@alap2.anarazel.de
M src/backend/access/heap/pruneheap.c
Cope with heap_fetch failure while locking an update chain
commit : fbface6f946242571f4acbfa9a74727c073748ba
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Nov 2013 17:45:25 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Nov 2013 17:45:25 -0300
The reason for the fetch failure is that the tuple was removed because
it was dead; so the failure is innocuous and can be ignored. Moreover,
there's no need for further work and we can return success to the caller
immediately. EvalPlanQualFetch is doing something very similar to this
already.
Report and test case from Andres Freund in
20131124000203.GA4403@alap2.anarazel.de
M src/backend/access/heap/heapam.c
doc: Put data types in alphabetical order
commit : 19ffa951e6ede713fc1298c1d7a53f1eab3958c4
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 27 Nov 2013 21:50:27 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 27 Nov 2013 21:50:27 -0500
From: Andreas Karlsson <andreas@proxel.se>
M doc/src/sgml/datatype.sgml
Fix stale-pointer problem in fast-path locking logic.
commit : d32e8387bac15ad353029c259e832f78d456c7a8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 Nov 2013 18:10:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 Nov 2013 18:10:03 -0500
When acquiring a lock in fast-path mode, we must reset the locallock
object's lock and proclock fields to NULL. They are not necessarily that
way to start with, because the locallock could be left over from a failed
lock acquisition attempt earlier in the transaction. Failure to do this
led to all sorts of interesting misbehaviors when LockRelease tried to
clean up no-longer-related lock and proclock objects in shared memory.
Per report from Dan Wood.
In passing, modify LockRelease to elog not just Assert if it doesn't find
lock and proclock objects for a formerly fast-path lock, matching the code
in FastPathGetRelationLockEntry and LockRefindAndRelease. This isn't a
bug but it will help in diagnosing any future bugs in this area.
Also, modify FastPathTransferRelationLocks and FastPathGetRelationLockEntry
to break out of their loops over the fastpath array once they've found the
sole matching entry. This was inconsistently done in some search loops
and not others.
Improve assorted related comments, too.
Back-patch to 9.2 where the fast-path mechanism was introduced.
M src/backend/storage/lmgr/lock.c
M src/include/storage/lock.h
Don't update relfrozenxid if any pages were skipped.
commit : 08302a39743c085a4be1d218e61abf225ab13bab
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 27 Nov 2013 13:10:16 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 27 Nov 2013 13:10:16 +0200
Vacuum recognizes that it can update relfrozenxid by checking whether it has
processed all pages of a relation. Unfortunately it performed that check
after truncating the dead pages at the end of the relation, and used the new
number of pages to decide whether all pages have been scanned. If the new
number of pages happened to be smaller or equal to the number of pages
scanned, it incorrectly decided that all pages were scanned.
This can lead to relfrozenxid being updated, even though some pages were
skipped that still contain old XIDs. That can lead to data loss due to xid
wraparounds with some rows suddenly missing. This likely has escaped notice
so far because it takes a large number (~2^31) of xids being used to see the
effect, while a full-table vacuum before that would fix the issue.
The incorrect logic was introduced by commit
b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8. Backpatch this fix down to 8.4,
like that commit.
Andres Freund, with some modifications by me.
M src/backend/commands/vacuumlazy.c
ECPG: Fix searching for quoted cursor names case-sensitively.
commit : dcb05900b1c78c05bd1fb9f9e067417afbd59773
author : Michael Meskes <meskes@postgresql.org>
date : Wed, 27 Nov 2013 11:02:13 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Wed, 27 Nov 2013 11:02:13 +0100
Patch by Böszörményi Zoltán <zb@cybertec.at>
M src/interfaces/ecpg/preproc/ecpg.addons
M src/interfaces/ecpg/preproc/ecpg.header
M src/interfaces/ecpg/preproc/ecpg.trailer
Documentation fix for ecpg.
commit : 55c18bcfa2843f2b529da878e3f601b91102db1f
author : Michael Meskes <meskes@postgresql.org>
date : Wed, 27 Nov 2013 11:03:59 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Wed, 27 Nov 2013 11:03:59 +0100
The latest fixes removed a limitation that was still in the docs, so Zoltan updated the docs, too.
M doc/src/sgml/ecpg.sgml
Fix typo in release note.
commit : d982881487b169bb72629951a2adea4d3538fece
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 27 Nov 2013 13:45:41 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 27 Nov 2013 13:45:41 +0900
Backpatch to 9.1.
Josh Kupershmidt
M doc/src/sgml/release-9.1.sgml
ECPG: Fix offset to NULL/size indicator array.
commit : a387f56cebe3b61172e196d6b8e3068b7b18919a
author : Michael Meskes <meskes@postgresql.org>
date : Tue, 26 Nov 2013 17:16:39 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Tue, 26 Nov 2013 17:16:39 +0100
Patch by Boszormenyi Zoltan <zb@cybertec.at>
M src/interfaces/ecpg/ecpglib/data.c
ECPG: Make the preprocessor emit ';' if the variable type for a list of variables is varchar. This fixes this test case:
commit : b3866bc2b9dbffeb61b1082c7105707360ed57d9
author : Michael Meskes <meskes@postgresql.org>
date : Tue, 26 Nov 2013 17:12:39 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Tue, 26 Nov 2013 17:12:39 +0100
int main(void)
{
exec sql begin declare section;
varchar a[50], b[50];
exec sql end declare section;
return 0;
}
Since varchars are internally turned into custom structs and
the type name is emitted for these variable declarations,
the preprocessed code previously had:
struct varchar_1 { ... } a _,_ struct varchar_2 { ... } b ;
The comma in the generated C file was a syntax error.
There are no regression test changes since it's not exercised.
Patch by Boszormenyi Zoltan <zb@cybertec.at>
M src/interfaces/ecpg/preproc/ecpg.trailer
Defend against bad trigger definitions in contrib/lo's lo_manage() trigger.
commit : af1288e6812367dfb11f5b3cadb432fed74e2cd7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Nov 2013 22:45:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Nov 2013 22:45:46 -0500
This function formerly crashed if called as a statement-level trigger,
or if a column-name argument wasn't given.
In passing, add the trigger name to all error messages from the function.
(None of them are expected cases, so this shouldn't pose any compatibility
risk.)
Marc Cousin, reviewed by Sawada Masahiko
M contrib/lo/lo.c
Fix array slicing of int2vector and oidvector values.
commit : c4d3cd3dc8514147cc8d30a648e4970a2a876ca8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Nov 2013 20:04:00 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Nov 2013 20:04:00 -0500
The previous coding labeled expressions such as pg_index.indkey[1:3] as
being of int2vector type; which is not right because the subscript bounds
of such a result don't, in general, satisfy the restrictions of int2vector.
To fix, implicitly promote the result of slicing int2vector to int2[],
or oidvector to oid[]. This is similar to what we've done with domains
over arrays, which is a good analogy because these types are very much
like restricted domains of the corresponding regular-array types.
A side-effect is that we now also forbid array-element updates on such
columns, eg while "update pg_index set indkey[4] = 42" would have worked
before if you were superuser (and corrupted your catalogs irretrievably,
no doubt) it's now disallowed. This seems like a good thing since, again,
some choices of subscripting would've led to results not satisfying the
restrictions of int2vector. The case of an array-slice update was
rejected before, though with a different error message than you get now.
We could make these cases work in future if we added a cast from int2[]
to int2vector (with a cast function checking the subscript restrictions)
but it seems unlikely that there's any value in that.
Per report from Ronan Dunklau. Back-patch to all supported branches
because of the crash risks involved.
M src/backend/parser/parse_node.c
M src/backend/parser/parse_target.c
M src/include/catalog/pg_type.h
Ensure _dosmaperr() actually sets errno correctly.
commit : 69eb861695be52706217ec58830178d0a82d53ce
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Nov 2013 18:24:26 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Nov 2013 18:24:26 -0500
If logging is enabled, either ereport() or fprintf() might stomp on errno
internally, causing this function to return the wrong result. That might
only end in a misleading error report, but in any code that's examining
errno to decide what to do next, the consequences could be far graver.
This has been broken since the very first version of this file in 2006
... it's a bit astonishing that we didn't identify this long ago.
Reported by Amit Kapila, though this isn't his proposed fix.
M src/port/win32error.c
Avoid potential buffer overflow crash
commit : 0f8ff3e467b2b52e8c0c44b01a1f9a4495949ba1
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 23 Nov 2013 07:25:37 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 23 Nov 2013 07:25:37 -0500
A pointer to a C string was treated as a pointer to a "name" datum and
passed to SPI_execute_plan(). This pointer would then end up being
passed through datumCopy(), which would try to copy the entire 64 bytes
of name data, thus running past the end of the C string. Fix by
converting the string to a proper name structure.
Found by LLVM AddressSanitizer.
M src/backend/utils/adt/ruleutils.c
Flatten join alias Vars before pulling up targetlist items from a subquery.
commit : 6bc68af1dc29db9afc49e77f70de0dec7653c8e5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Nov 2013 14:37:25 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Nov 2013 14:37:25 -0500
pullup_replace_vars()'s decisions about whether a pulled-up replacement
expression needs to be wrapped in a PlaceHolderVar depend on the assumption
that what looks like a Var behaves like a Var. However, if the Var is a
join alias reference, later flattening of join aliases might replace the
Var with something that's not a Var at all, and should have been wrapped.
To fix, do a forcible pass of flatten_join_alias_vars() on the subquery
targetlist before we start to copy items out of it. We'll re-run that
processing on the pulled-up expressions later, but that's harmless.
Per report from Ken Tanzer; the added regression test case is based on his
example. This bug has been there since the PlaceHolderVar mechanism was
invented, but has escaped detection because the circumstances that trigger
it are fairly narrow. You need a flattenable query underneath an outer
join, which contains another flattenable query inside a join of its own,
with a dangerous expression (a constant or something else non-strict)
in that one's targetlist.
Having seen this, I'm wondering if it wouldn't be prudent to do all
alias-variable flattening earlier, perhaps even in the rewriter.
But that would probably not be a back-patchable change.
M src/backend/optimizer/prep/prepjointree.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix quoting in help messages in uuid-ossp extension scripts.
commit : 72dcdc6f7874d6ba4a51cc283b971296cb36ba2b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Nov 2013 12:07:53 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Nov 2013 12:07:53 -0500
The command we're telling people to type needs to include double-quoting
around the unfortunately-chosen extension name. Twiddle the textual
quoting so that it looks somewhat sane. Per gripe from roadrunner6.
M contrib/uuid-ossp/uuid-ossp–1.0.sql
M contrib/uuid-ossp/uuid-ossp–unpackaged–1.0.sql
Fix Hot-Standby initialization of clog and subtrans.
commit : 3e10cc4921e619ea1f80c175591ad7177d0c8b4f
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Nov 2013 14:38:59 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Nov 2013 14:38:59 +0200
These bugs can cause data loss on standbys started with hot_standby=on at
the moment they start to accept read only queries, by marking committed
transactions as uncommited. The likelihood of such corruptions is small
unless the primary has a high transaction rate.
5a031a5556ff83b8a9646892715d7fef415b83c3 fixed bugs in HS's startup logic
by maintaining less state until at least STANDBY_SNAPSHOT_PENDING state
was reached, missing the fact that both clog and subtrans are written to
before that. This only failed to fail in common cases because the usage
of ExtendCLOG in procarray.c was superflous since clog extensions are
actually WAL logged.
f44eedc3f0f347a856eea8590730769125964597/I then tried to fix the missing
extensions of pg_subtrans due to the former commit's changes - which are
not WAL logged - by performing the extensions when switching to a state
> STANDBY_INITIALIZED and not performing xid assignments before that -
again missing the fact that ExtendCLOG is unneccessary - but screwed up
twice: Once because latestObservedXid wasn't updated anymore in that
state due to the earlier commit and once by having an off-by-one error in
the loop performing extensions. This means that whenever a
CLOG_XACTS_PER_PAGE (32768 with default settings) boundary was crossed
between the start of the checkpoint recovery started from and the first
xl_running_xact record old transactions commit bits in pg_clog could be
overwritten if they started and committed in that window.
Fix this mess by not performing ExtendCLOG() in HS at all anymore since
it's unneeded and evidently dangerous and by performing subtrans
extensions even before reaching STANDBY_SNAPSHOT_PENDING.
Analysis and patch by Andres Freund. Reported by Christophe Pettus.
Backpatch down to 9.0, like the previous commit that caused this.
M src/backend/access/transam/clog.c
M src/backend/storage/ipc/procarray.c
Fix pg_isready to handle -d option properly.
commit : 844534dd4d2237011eff928bdf4306a6ababcdb0
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 21 Nov 2013 21:52:03 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 21 Nov 2013 21:52:03 +0900
Previously, -d option for pg_isready was broken. When the name of the
database was specified by -d option, pg_isready failed with an error.
When the conninfo specified by -d option contained the setting of the
host name but not Numeric IP address (i.e., hostaddr), pg_isready
displayed wrong connection message. -d option could not handle a valid
URI prefix at all. This commit fixes these bugs of pg_isready.
Backpatch to 9.3, where pg_isready was introduced.
Per report from Josh Berkus and Robert Haas.
Original patch by Fabrízio de Royes Mello, heavily modified by me.
M src/bin/scripts/pg_isready.c
docs: update page format to specify page checksum field
commit : 57282cdedaa64c0db451a6e05884a76195f21f0c
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 19 Nov 2013 16:54:42 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 19 Nov 2013 16:54:42 -0500
Backpatch to 9.3
Per report from Steffen Hildebrandt
M doc/src/sgml/storage.sgml
pg_upgrade: Report full disk better
commit : 8ca75671bd583f2e814c865941da464d2419312c
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 18 Nov 2013 21:49:40 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 18 Nov 2013 21:49:40 -0500
Previously, pg_upgrade would abort copy_file() on a short write without
setting errno, which the caller would report as an error with the
message "Success". We assume ENOSPC in that case, as we do elsewhere in
the code. Also set errno in some other error cases in copy_file() to
avoid bogus "Success" error messages.
This was broken in 6b711cf37c228749b6a8cef50e16e3c587d18dd4, so 9.2 and
before are OK.
M contrib/pg_upgrade/file.c
Count locked pages that don't need vacuuming as scanned.
commit : ea2bb1b47d7629a17dbc0c7da66cf063f8d3a768
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 18 Nov 2013 09:51:09 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 18 Nov 2013 09:51:09 +0200
Previously, if VACUUM skipped vacuuming a page because it's pinned, it
didn't count that page as scanned. However, that meant that relfrozenxid
was not bumped up either, which prevented anti-wraparound vacuum from
doing its job.
Report by Миша Тюрин, analysis and patch by Sergey Burladyn and Jeff Janes.
Backpatch to 9.2, where the skip-locked-pages behavior was introduced.
M src/backend/commands/vacuumlazy.c
Fix incorrect loop counts in tidbitmap.c.
commit : 4b61f6783793a362423e511d76027e5983fc241c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Nov 2013 18:34:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Nov 2013 18:34:14 -0500
A couple of places that should have been iterating over WORDS_PER_CHUNK
words were iterating over WORDS_PER_PAGE words instead. This thinko
accidentally failed to fail, because (at least on common architectures
with default BLCKSZ) WORDS_PER_CHUNK is a bit less than WORDS_PER_PAGE,
and the extra words being looked at were always zero so nothing happened.
Still, it's a bug waiting to happen if anybody ever fools with the
parameters affecting TIDBitmap sizes, and it's a small waste of cycles
too. So back-patch to all active branches.
Etsuro Fujita
M src/backend/nodes/tidbitmap.c
Compute correct em_nullable_relids in get_eclass_for_sort_expr().
commit : 1c0dfaa68fa491f2ec4c6f7905246ef07e504d4c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Nov 2013 16:46:21 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Nov 2013 16:46:21 -0500
Bug #8591 from Claudio Freire demonstrates that get_eclass_for_sort_expr
must be able to compute valid em_nullable_relids for any new equivalence
class members it creates. I'd worried about this in the commit message
for db9f0e1d9a4a0842c814a464cdc9758c3f20b96c, but claimed that it wasn't a
problem because multi-member ECs should already exist when it runs. That
is transparently wrong, though, because this function is also called by
initialize_mergeclause_eclasses, which runs during deconstruct_jointree.
The example given in the bug report (which the new regression test item
is based upon) fails because the COALESCE() expression is first seen by
initialize_mergeclause_eclasses rather than process_equivalence.
Fixing this requires passing the appropriate nullable_relids set to
get_eclass_for_sort_expr, and it requires new code to compute that set
for top-level expressions such as ORDER BY, GROUP BY, etc. We store
the top-level nullable_relids in a new field in PlannerInfo to avoid
computing it many times. In the back branches, I've added the new
field at the end of the struct to minimize ABI breakage for planner
plugins. There doesn't seem to be a good alternative to changing
get_eclass_for_sort_expr's API signature, though. There probably aren't
any third-party extensions calling that function directly; moreover,
if there are, they probably need to think about what to pass for
nullable_relids anyway.
Back-patch to 9.2, like the previous patch in this area.
M src/backend/nodes/outfuncs.c
M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/path/pathkeys.c
M src/backend/optimizer/plan/initsplan.c
M src/include/nodes/relation.h
M src/include/optimizer/paths.h
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
doc: Restore proper alphabetical order.
commit : 8674f1fba90df84910aca5cdc04b8bb19602755b
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 15 Nov 2013 08:44:18 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 15 Nov 2013 08:44:18 -0500
Colin 't Hart
M doc/src/sgml/reference.sgml
Clarify CREATE FUNCTION documentation about handling of typmods.
commit : a1c29c1fe153302c41c6c90815a5d73f2ceeb8a5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Nov 2013 13:26:33 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Nov 2013 13:26:33 -0500
The previous text was a bit misleading, as well as unnecessarily vague
about what information would be discarded. Per gripe from Craig Skinner.
M doc/src/sgml/ref/create_function.sgml
Fix doc links in README file to work with new website layout
commit : 2720c55c0986dd6368653579b93c369f7b477741
author : Magnus Hagander <magnus@hagander.net>
date : Tue, 12 Nov 2013 12:53:32 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Tue, 12 Nov 2013 12:53:32 +0100
Per report from Colin 't Hart
M README.git
Fix failure with whole-row reference to a subquery.
commit : e243bd79d98ff4dc5acc20a290dbdc1ad2e17e91
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Nov 2013 16:36:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Nov 2013 16:36:27 -0500
Simple oversight in commit 1cb108efb0e60d87e4adec38e7636b6e8efbeb57 ---
recursively examining a subquery output column is only sane if the
original Var refers to a single output column. Found by Kevin Grittner.
M src/backend/utils/adt/selfuncs.c
Fix ruleutils pretty-printing to not generate trailing whitespace.
commit : fbbd150a25676076b5ed0e68f77adafcf46c1f4d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Nov 2013 13:36:42 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Nov 2013 13:36:42 -0500
The pretty-printing logic in ruleutils.c operates by inserting a newline
and some indentation whitespace into strings that are already valid SQL.
This naturally results in leaving some trailing whitespace before the
newline in many cases; which can be annoying when processing the output
with other tools, as complained of by Joe Abbate. We can fix that in
a pretty localized fashion by deleting any trailing whitespace before
we append a pretty-printing newline. In addition, we have to modify the
code inserted by commit 2f582f76b1945929ff07116cd4639747ce9bb8a1 so that
we also delete trailing whitespace when transposing items from temporary
buffers into the main result string, when a temporary item starts with a
newline.
This results in rather voluminous changes to the regression test results,
but it's easily verified that they are only removal of trailing whitespace.
Back-patch to 9.3, because the aforementioned commit resulted in many
more cases of trailing whitespace than had occurred in earlier branches.
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/aggregates.out
M src/test/regress/expected/create_view.out
M src/test/regress/expected/matview.out
M src/test/regress/expected/polymorphism.out
M src/test/regress/expected/rules.out
M src/test/regress/expected/triggers.out
M src/test/regress/expected/with.out
Re-allow duplicate aliases within aliased JOINs.
commit : 04e6ee40206fa61dc856bf2840ce6bb198d5200c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Nov 2013 10:43:00 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Nov 2013 10:43:00 -0500
Although the SQL spec forbids duplicate table aliases, historically
we've allowed queries like
SELECT ... FROM tab1 x CROSS JOIN (tab2 x CROSS JOIN tab3 y) z
on the grounds that the aliased join (z) hides the aliases within it,
therefore there is no conflict between the two RTEs named "x". The
LATERAL patch broke this, on the misguided basis that "x" could be
ambiguous if tab3 were a LATERAL subquery. To avoid breaking existing
queries, it's better to allow this situation and complain only if
tab3 actually does contain an ambiguous reference. We need only remove
the check that was throwing an error, because the column lookup code
is already prepared to handle ambiguous references. Per bug #8444.
M src/backend/parser/parse_clause.c
M src/backend/parser/parse_relation.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Don't abort pg_basebackup when receiving empty WAL block
commit : 8e41c621a625f154e96f40ce688a036520cb59aa
author : Magnus Hagander <magnus@hagander.net>
date : Mon, 11 Nov 2013 14:59:55 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Mon, 11 Nov 2013 14:59:55 +0100
This is a similar fix as c6ec8793aa59d1842082e14b4b4aae7d4bd883fd
9.2. This should never happen in 9.3 and newer since the special case
cannot happen there, but this patch synchronizes up the code so there
is no confusion on why they're different. An empty block is as harmless
in 9.3 as it was in 9.2, and can safely be ignored.
M src/bin/pg_basebackup/receivelog.c
Fix race condition in GIN posting tree page deletion.
commit : fc545a2548a4a2be1a66c6a4a8c36ee7b4dc264c
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 8 Nov 2013 22:21:42 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 8 Nov 2013 22:21:42 +0200
If a page is deleted, and reused for something else, just as a search is
following a rightlink to it from its left sibling, the search would continue
scanning whatever the new contents of the page are. That could lead to
incorrect query results, or even something more curious if the page is
reused for a different kind of a page.
To fix, modify the search algorithm to lock the next page before releasing
the previous one, and refrain from deleting pages from the leftmost branch
of the tree.
Add a new Concurrency section to the README, explaining why this works.
There is a lot more one could say about concurrency in GIN, but that's for
another patch.
Backpatch to all supported versions.
M src/backend/access/gin/README
M src/backend/access/gin/ginbtree.c
M src/backend/access/gin/ginget.c
M src/backend/access/gin/ginvacuum.c
M src/include/access/gin_private.h
Make contain_volatile_functions/contain_mutable_functions look into SubLinks.
commit : 9548bee2b19bee71e565a0a0aedd4d38ccb10a91
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 8 Nov 2013 11:37:00 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 8 Nov 2013 11:37:00 -0500
This change prevents us from doing inappropriate subquery flattening in
cases such as dangerous functions hidden inside a sub-SELECT in the
targetlist of another sub-SELECT. That could result in unexpected behavior
due to multiple evaluations of a volatile function, as in a recent
complaint from Etienne Dube. It's been questionable from the very
beginning whether these functions should look into subqueries (as noted in
their comments), and this case seems to provide proof that they should.
Because the new code only descends into SubLinks, not SubPlans or
InitPlans, the change only affects the planner's behavior during
prepjointree processing and not later on --- for example, you can still get
it to use a volatile function in an indexqual if you wrap the function in
(SELECT ...). That's a historical behavior, for sure, but it's reasonable
given that the executor's evaluation rules for subplans don't depend on
whether there are volatile functions inside them. In any case, we need to
constrain the behavioral change as narrowly as we can to make this
reasonable to back-patch.
M src/backend/optimizer/util/clauses.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql
Fix subtly-wrong volatility checking in BeginCopyFrom().
commit : 3c24b08f9bdc191d9e389dbcd97dbfb4cdb546d4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 8 Nov 2013 08:59:43 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 8 Nov 2013 08:59:43 -0500
contain_volatile_functions() is best applied to the output of
expression_planner(), not its input, so that insertion of function
default arguments and constant-folding have been done. (See comments
at CheckMutability, for instance.) It's perhaps unlikely that anyone
will notice a difference in practice, but still we should do it properly.
In passing, change variable type from Node* to Expr* to reduce the net
number of casts needed.
Noted while perusing uses of contain_volatile_functions().
M src/backend/commands/copy.c
Be more robust when strerror() doesn't give a useful result.
commit : e3480438e89f74019f271b1b5501bb9eed2e0d2a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 7 Nov 2013 16:33:18 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 7 Nov 2013 16:33:18 -0500
Back-patch commits 8e68816cc2567642c6fcca4eaac66c25e0ae5ced and
8dace66e0735ca39b779922d02c24ea2686e6521 into the stable branches.
Buildfarm testing revealed no great portability surprises, and it
seems useful to have this robustness improvement in all branches.
M src/backend/utils/error/elog.c
Prevent display of dropped columns in row constraint violation messages.
commit : df5d5f1dc75137db36099eb6a3759bde678828ad
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 7 Nov 2013 14:41:39 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 7 Nov 2013 14:41:39 -0500
ExecBuildSlotValueDescription() printed "null" for each dropped column in
a row being complained of by ExecConstraints(). This has some sanity in
terms of the underlying implementation, but is of course pretty surprising
to users. To fix, we must pass the target relation's descriptor to
ExecBuildSlotValueDescription(), because the slot descriptor it had been
using doesn't get labeled with attisdropped markers.
Per bug #8408 from Maxim Boguk. Back-patch to 9.2 where the feature of
printing row values in NOT NULL and CHECK constraint violation messages
was introduced.
Michael Paquier and Tom Lane
M src/backend/executor/execMain.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix generation of MergeAppend plans for optimized min/max on expressions.
commit : 5d0731da521f090f80ea39529fe274ac6d6bffa1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 7 Nov 2013 13:13:15 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 7 Nov 2013 13:13:15 -0500
Before jamming a desired targetlist into a plan node, one really ought to
make sure the plan node can handle projections, and insert a buffering
Result plan node if not. planagg.c forgot to do this, which is a hangover
from the days when it only dealt with IndexScan plan types. MergeAppend
doesn't project though, not to mention that it gets unhappy if you remove
its possibly-resjunk sort columns. The code accidentally failed to fail
for cases in which the min/max argument was a simple Var, because the new
targetlist would be equivalent to the original "flat" tlist anyway.
For any more complex case, it's been broken since 9.1 where we introduced
the ability to optimize min/max using MergeAppend, as reported by Raphael
Bauduin. Fix by duplicating the logic from grouping_planner that decides
whether we need a Result node.
In 9.2 and 9.1, this requires back-porting the tlist_same_exprs() function
introduced in commit 4387cf956b9eb13aad569634e0c4df081d76e2e3, else we'd
uselessly add a Result node in cases that worked before. It's rather
tempting to back-patch that whole commit so that we can avoid extra Result
nodes in mainline cases too; but I'll refrain, since that code hasn't
really seen all that much field testing yet.
M src/backend/optimizer/plan/planagg.c
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Support default arguments and named-argument notation for window functions.
commit : 66e6daa3e1a0c94f2fcf3463757d478c76c38b3a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 6 Nov 2013 13:26:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 6 Nov 2013 13:26:34 -0500
These things didn't work because the planner omitted to do the necessary
preprocessing of a WindowFunc's argument list. Add the few dozen lines
of code needed to handle that.
Although this sounds like a feature addition, it's really a bug fix because
the default-argument case was likely to crash previously, due to lack of
checking of the number of supplied arguments in the built-in window
functions. It's not a security issue because there's no way for a
non-superuser to create a window function definition with defaults that
refers to a built-in C function, but nonetheless people might be annoyed
that it crashes rather than producing a useful error message. So
back-patch as far as the patch applies easily, which turns out to be 9.2.
I'll put a band-aid in earlier versions as a separate patch.
(Note that these features still don't work for aggregates, and fixing that
case will be harder since we represent aggregate arg lists as target lists
not bare expression lists. There's no crash risk though because CREATE
AGGREGATE doesn't accept defaults, and we reject named-argument notation
when parsing an aggregate call.)
M doc/src/sgml/syntax.sgml
M src/backend/optimizer/util/clauses.c
M src/backend/parser/parse_func.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/window.out
M src/test/regress/sql/window.sql
Keep heap open until new heap generated in RMV.
commit : bc06faeb78c0e66927cd04f46ed8b5d41ab18427
author : Kevin Grittner <kgrittn@postgresql.org>
date : Wed, 6 Nov 2013 12:26:36 -0600
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Wed, 6 Nov 2013 12:26:36 -0600
Early close became apparent when invalidation messages were
processed in a new location under CLOBBER_CACHE_ALWAYS builds, due
to additional locking.
Back-patch to 9.3
M src/backend/commands/matview.c
Improve the error message given for modifying a window with frame clause.
commit : b47487138533075be1c558310685d4d822b7acb9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 Nov 2013 21:58:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 Nov 2013 21:58:12 -0500
For rather inscrutable reasons, SQL:2008 disallows copying-and-modifying a
window definition that has any explicit framing clause. The error message
we gave for this only made sense if the referencing window definition
itself contains an explicit framing clause, which it might well not.
Moreover, in the context of an OVER clause it's not exactly obvious that
"OVER (windowname)" implies copy-and-modify while "OVER windowname" does
not. This has led to multiple complaints, eg bug #5199 from Iliya
Krapchatov. Change to a hopefully more intelligible error message, and
in the case where we have just "OVER (windowname)", add a HINT suggesting
that omitting the parentheses will fix it. Also improve the related
documentation. Back-patch to all supported branches.
M doc/src/sgml/syntax.sgml
M src/backend/parser/parse_clause.c
Fix breakage of MV column name list usage.
commit : 5b6ee03a31ee695b8e57e27bb1cd82b4f0bb2ef0
author : Kevin Grittner <kgrittn@postgresql.org>
date : Mon, 4 Nov 2013 14:45:18 -0600
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Mon, 4 Nov 2013 14:45:18 -0600
Per bug report from Tomonari Katsumata.
Back-patch to 9.3.
M src/backend/rewrite/rewriteDefine.c
M src/test/regress/expected/matview.out
M src/test/regress/sql/matview.sql
Fix parsing of xlog file name in pg_receivexlog.
commit : e843d12ebc6cfea9704eca5da62a78ac34ad2602
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 4 Nov 2013 10:51:37 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 4 Nov 2013 10:51:37 +0200
The parsing of WAL filenames of segments larger than > 255 was broken,
making pg_receivexlog unable to restart streaming after stopping it.
The bug was introduced by the changes in 9.3 to represent WAL segment number
as a 64-bit integer instead of two ints, log and seg. To fix, replace the
plain sscanf call with XLogFromFileName macro, which does the conversion
from log+seg to a 64-bit integer correcly.
Reported by Mika Eloranta.
M src/bin/pg_basebackup/pg_receivexlog.c
Prevent memory leaks from accumulating across printtup() calls.
commit : da2c6a919533e29623b03a2213b72ece69875bb3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Nov 2013 11:33:09 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Nov 2013 11:33:09 -0500
Historically, printtup() has assumed that it could prevent memory leakage
by pfree'ing the string result of each output function and manually
managing detoasting of toasted values. This amounts to assuming that
datatype output functions never leak any memory internally; an assumption
we've already decided to be bogus elsewhere, for example in COPY OUT.
range_out in particular is known to leak multiple kilobytes per call, as
noted in bug #8573 from Godfried Vanluffelen. While we could go in and fix
that leak, it wouldn't be very notationally convenient, and in any case
there have been and undoubtedly will again be other leaks in other output
functions. So what seems like the best solution is to run the output
functions in a temporary memory context that can be reset after each row,
as we're doing in COPY OUT. Some quick experimentation suggests this is
actually a tad faster than the retail pfree's anyway.
This patch fixes all the variants of printtup, except for debugtup()
which is used in standalone mode. It doesn't seem worth worrying
about query-lifespan leaks in standalone mode, and fixing that case
would be a bit tedious since debugtup() doesn't currently have any
startup or shutdown functions.
While at it, remove manual detoast management from several other
output-function call sites that had copied it from printtup(). This
doesn't make a lot of difference right now, but in view of recent
discussions about supporting "non-flattened" Datums, we're going to
want that code gone eventually anyway.
Back-patch to 9.2 where range_out was introduced. We might eventually
decide to back-patch this further, but in the absence of known major
leaks in older output functions, I'll refrain for now.
M src/backend/access/common/printtup.c
M src/backend/bootstrap/bootstrap.c
M src/backend/executor/spi.c
M src/backend/utils/adt/rowtypes.c
Changed test case slightly so it doesn't have an unused typedef.
commit : c142a1acf7fa30cc423c01a9409a5e26cbf9ed87
author : Michael Meskes <meskes@postgresql.org>
date : Sun, 3 Nov 2013 15:37:34 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Sun, 3 Nov 2013 15:37:34 +0100
M src/interfaces/ecpg/test/expected/preproc-define.c
M src/interfaces/ecpg/test/expected/preproc-define.stderr
M src/interfaces/ecpg/test/preproc/define.pgc
Acquire appropriate locks when rewriting during RMV.
commit : b21aed3964794f3ebfbfee9324badf1430b1efbc
author : Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 2 Nov 2013 19:18:41 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 2 Nov 2013 19:18:41 -0500
Since the query has not been freshly parsed when executing REFRESH
MATERIALIZED VIEW, locks must be explicitly taken before rewrite.
Backpatch to 9.3.
Andres Freund
M src/backend/commands/matview.c
Fix subquery reference to non-populated MV in CMV.
commit : b2cd72cbbdd2a1b657d7dc874fcc9f1c1d83d8e3
author : Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 2 Nov 2013 18:31:41 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 2 Nov 2013 18:31:41 -0500
A subquery reference to a matview should be allowed by CREATE
MATERIALIZED VIEW WITH NO DATA, just like a direct reference is.
Per bug report from Laurent Sartran.
Backpatch to 9.3.
M src/backend/executor/execMain.c
M src/test/regress/expected/matview.out
M src/test/regress/sql/matview.sql
Retry after buffer locking failure during SPGiST index creation.
commit : 86dab9c8addd2898abc0feddc4e7f1ef0cd786f4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 2 Nov 2013 16:45:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 2 Nov 2013 16:45:42 -0400
The original coding thought this case was impossible, but it can happen
if the bgwriter or checkpointer processes decide to write out an index
page while creation is still proceeding, leading to a bogus "unexpected
spgdoinsert() failure" error. Problem reported by Jonathan S. Katz.
Teodor Sigaev
M src/backend/access/spgist/spgdoinsert.c
M src/backend/access/spgist/spginsert.c
Ensure all files created for a single BufFile have the same resource owner.
commit : 14d4548f1c9ba21d2c1eb26e4169e6fee3b3fd68
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Nov 2013 16:09:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Nov 2013 16:09:52 -0400
Callers expect that they only have to set the right resource owner when
creating a BufFile, not during subsequent operations on it. While we could
insist this be fixed at the caller level, it seems more sensible for the
BufFile to take care of it. Without this, some temp files belonging to
a BufFile can go away too soon, eg at the end of a subtransaction,
leading to errors or crashes.
Reported and fixed by Andres Freund. Back-patch to all active branches.
M src/backend/storage/file/buffile.c
Fix some odd behaviors when using a SQL-style simple GMT offset timezone.
commit : 2650c5cf4beb727e739f71a77369b01bf6daaf60
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Nov 2013 12:13:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Nov 2013 12:13:23 -0400
Formerly, when using a SQL-spec timezone setting with a fixed GMT offset
(called a "brute force" timezone in the code), the session_timezone
variable was not updated to match the nominal timezone; rather, all code
was expected to ignore session_timezone if HasCTZSet was true. This is
of course obviously fragile, though a search of the code finds only
timeofday() failing to honor the rule. A bigger problem was that
DetermineTimeZoneOffset() supposed that if its pg_tz parameter was
pointer-equal to session_timezone, then HasCTZSet should override the
parameter. This would cause datetime input containing an explicit zone
name to be treated as referencing the brute-force zone instead, if the
zone name happened to match the session timezone that had prevailed
before installing the brute-force zone setting (as reported in bug #8572).
The same malady could affect AT TIME ZONE operators.
To fix, set up session_timezone so that it matches the brute-force zone
specification, which we can do using the POSIX timezone definition syntax
"<abbrev>offset", and get rid of the bogus lookaside check in
DetermineTimeZoneOffset(). Aside from fixing the erroneous behavior in
datetime parsing and AT TIME ZONE, this will cause the timeofday() function
to print its result in the user-requested time zone rather than some
previously-set zone. It might also affect results in third-party
extensions, if there are any that make use of session_timezone without
considering HasCTZSet, but in all cases the new behavior should be saner
than before.
Back-patch to all supported branches.
M src/backend/commands/variable.c
M src/backend/utils/adt/datetime.c
M src/include/pgtime.h
M src/test/regress/expected/horology.out
M src/test/regress/sql/horology.sql
M src/timezone/pgtz.c
Prevent using strncpy with src == dest in TupleDescInitEntry.
commit : 27deb0480c9a9b437d6e77685c45d9ced09ba1ec
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Oct 2013 20:49:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Oct 2013 20:49:28 -0400
The C and POSIX standards state that strncpy's behavior is undefined when
source and destination areas overlap. While it remains dubious whether any
implementations really misbehave when the pointers are exactly equal, some
platforms are now starting to force the issue by complaining when an
undefined call occurs. (In particular OS X 10.9 has been seen to dump core
here, though the exact set of circumstances needed to trigger that remain
elusive. Similar behavior can be expected to be optional on Linux and
other platforms in the near future.) So tweak the code to explicitly do
nothing when nothing need be done.
Back-patch to all active branches. In HEAD, this also lets us get rid of
an exception in valgrind.supp.
Per discussion of a report from Matthias Schmitt.
M src/backend/access/common/tupdesc.c
Work around NetBSD shell issue in pg_upgrade test script.
commit : bd04dfba9f7e10274a6b2558e57e274403161373
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 28 Oct 2013 11:45:50 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 28 Oct 2013 11:45:50 -0400
The NetBSD shell apparently returns non-zero from an unset command if
the variable is already unset. This matters when, as in pg_upgrade's
test.sh, we are working under 'set -e'. To protect against this, we
first set the PG variables to an empty string before unsetting them
completely.
Error found on buildfarm member coypu, solution from Rémi Zara.
M contrib/pg_upgrade/test.sh
Improve documentation about usage of FDW validator functions.
commit : 01c1b1aa25149674f9347f9d915533a53c33eff6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Oct 2013 10:28:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Oct 2013 10:28:35 -0400
SGML documentation, as well as code comments, failed to note that an FDW's
validator will be applied to foreign-table options for foreign tables using
the FDW.
Etsuro Fujita
M doc/src/sgml/ref/alter_foreign_data_wrapper.sgml
M doc/src/sgml/ref/create_foreign_data_wrapper.sgml
M src/backend/commands/foreigncmds.c
Plug memory leak when reloading config file.
commit : bb604d03abf1402764d384acb1ae36d379965126
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 24 Oct 2013 15:21:50 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 24 Oct 2013 15:21:50 +0300
The absolute path to config file was not pfreed. There are probably more
small leaks here and there in the config file reload code and assign hooks,
and in practice no-one reloads the config files frequently enough for it to
be a problem, but this one is trivial enough that might as well fix it.
Backpatch to 9.3 where the leak was introduced.
M src/backend/utils/misc/guc-file.l
Fix memory leak when an empty ident file is reloaded.
commit : b0aa17706e210dec4e8d744eac1682e0c6a0a3b0
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 24 Oct 2013 14:03:26 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 24 Oct 2013 14:03:26 +0300
Hari Babu
M src/backend/libpq/hba.c
Fix typos in comments.
commit : 80eba5981e0fa8af93c3ea173745a13f2f38a043
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 24 Oct 2013 11:50:02 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 24 Oct 2013 11:50:02 +0300
M src/backend/access/transam/xlogreader.c
Fix two bugs in setting the vm bit of empty pages.
commit : f90d7426ed3605ab925910a387783163763833fa
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 23 Oct 2013 14:03:54 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 23 Oct 2013 14:03:54 +0300
Use a critical section when setting the all-visible flag on an empty page,
and WAL-logging it. log_newpage_buffer() contains an assertion that it
must be called inside a critical section, and it's the right thing to do
when modifying a buffer anyway.
Also, the page should be marked dirty before calling log_newpage_buffer(),
per the comment in log_newpage_buffer() and src/backend/access/transam/README.
Patch by Andres Freund, in response to my report. Backpatch to 9.2, like
the patch that introduced these bugs (a6370fd9).
M src/backend/commands/vacuumlazy.c
Add libpgcommon to backend gettext source files
commit : 627f2165666cf30d011a8702750659c0cf9ca312
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 19 Oct 2013 13:49:05 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 19 Oct 2013 13:49:05 -0400
This ought to have been done when libpgcommon was split off from
libpgport.
M src/backend/nls.mk
Return valid json when converting an empty hstore.
commit : bfb327ac1d9a55fe0cd83fa96d4ba471dd30efaf
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 17 Oct 2013 11:09:55 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 17 Oct 2013 11:09:55 -0400
Oskari Saarenmaa.
M contrib/hstore/hstore_io.c
docs: correct 9.1 and 9.2 release note mention of timeline switch fix
commit : 41b46ed8a269e502f95c54fc30280ef9464d9d18
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 15 Oct 2013 10:34:05 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 15 Oct 2013 10:34:05 -0400
Backpatch through 9.1.
KONDO Mitsumasa
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
doc: Fix table column number declaration
commit : d42d839e52e907b202d9355d5151d9b196f75f03
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 10 Oct 2013 21:17:31 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 10 Oct 2013 21:17:31 -0400
M doc/src/sgml/pgcrypto.sgml
doc: fix typo in release notes
commit : 7453b8db75a0216fbcc3843e14c2c7266e6a15be
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 9 Oct 2013 08:44:52 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 9 Oct 2013 08:44:52 -0400
Backpatch through 8.4
Per suggestion by Amit Langote
M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
docs: clarify references to md5 hash and md5 crypt in pgcrypto docs
commit : ac9558c2fd18faf4f107bb66ee03bad85593e287
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 8 Oct 2013 12:25:18 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 8 Oct 2013 12:25:18 -0400
Backpatch to 9.3.X.
Suggestion from Richard Neill
M doc/src/sgml/pgcrypto.sgml