commit : 697becf743b3176a038d78857b14976d441a0027 author : Tom Lane <email@example.com> date : Mon, 17 Mar 2014 15:37:27 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 17 Mar 2014 15:37:27 -0400
Release notes for 9.3.4, 9.2.8, 9.1.13, 9.0.17, 8.4.21.
commit : f0a8488ab74502fe376a4d542437b770299a3d79 author : Tom Lane <email@example.com> date : Mon, 17 Mar 2014 15:28:32 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 17 Mar 2014 15:28:32 -0400
Fix bug in clean shutdown of walsender that pg_receiving is connecting to.
commit : 65e8dbb1869db542c93333fc809f34c7d3f7d9bd author : Fujii Masao <email@example.com> date : Mon, 17 Mar 2014 20:42:35 +0900 committer: Fujii Masao <firstname.lastname@example.org> date : Mon, 17 Mar 2014 20:42:35 +0900
On clean shutdown, walsender waits for all WAL to be replicated to a standby, and exits. It determined whether that replication had been completed by checking whether its sent location had been equal to a standby's flush location. Unfortunately this condition never becomes true when the standby such as pg_receivexlog which always returns an invalid flush location is connecting to walsender, and then walsender waits forever. This commit changes walsender so that it just checks a standby's write location if a flush location is invalid. Back-patch to 9.1 where enough infrastructure for this exists.
plperl: Fix memory leak in hek2cstr
commit : f84997c7e6687548d0d92631dceb125f89e55a2b author : Alvaro Herrera <email@example.com> date : Sun, 16 Mar 2014 23:22:22 -0300 committer: Alvaro Herrera <firstname.lastname@example.org> date : Sun, 16 Mar 2014 23:22:22 -0300
Backpatch all the way back to 9.1, where it was introduced by commit 50d89d42. Reported by Sergey Burladyan in #9223 Author: Alex Hunsaker
commit : 8976360ea69389af5bc536abf1335a97c39c78b6 author : Peter Eisentraut <email@example.com> date : Sun, 16 Mar 2014 21:38:55 -0400 committer: Peter Eisentraut <firstname.lastname@example.org> date : Sun, 16 Mar 2014 21:38:55 -0400
Fix advertised dispsize for libpq's sslmode connection parameter.
commit : 6b736102e40dd970037a21e756696f8e22bd8e61 author : Tom Lane <email@example.com> date : Sun, 16 Mar 2014 21:43:49 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Sun, 16 Mar 2014 21:43:49 -0400
"8" was correct back when "disable" was the longest allowed value, but since "verify-full" was added, it should be "12". Given the lack of complaints, I wouldn't be surprised if nobody is actually using these values ... but still, if they're in the API, they should be right. Noticed while pursuing a different problem. It's been wrong for quite a long time, so back-patch to all supported branches.
Disable RandomizeBaseAddress on MSVC builds
commit : fae12f3310aa515fda9c7659d6ce9350176fb929 author : Magnus Hagander <email@example.com> date : Sun, 16 Mar 2014 11:46:20 +0100 committer: Magnus Hagander <firstname.lastname@example.org> date : Sun, 16 Mar 2014 11:46:20 +0100
This is a backpatch of 7f3e17b4827b61ad84e0774e3e43da4c57c4487f to 9.0 and 9.1. Patch by MauMau
Update time zone data files to tzdata release 2014a.
commit : 2df1bf21c77537043e058a6d03c42f0e8423902c author : Tom Lane <email@example.com> date : Sat, 15 Mar 2014 13:36:07 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Sat, 15 Mar 2014 13:36:07 -0400
DST law changes in Fiji, Turkey; historical changes in Israel, Ukraine.
Prevent interrupts while reporting non-ERROR elog messages.
commit : f16ca975500b7aab5026f164b1bc7bf833e2190b author : Tom Lane <email@example.com> date : Thu, 13 Mar 2014 20:59:51 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Thu, 13 Mar 2014 20:59:51 -0400
This should eliminate the risk of recursive entry to syslog(3), which appears to be the cause of the hang reported in bug #9551 from James Morton. Arguably, the real problem here is auth.c's willingness to turn on ImmediateInterruptOK while executing fairly wide swaths of backend code. We may well need to work at narrowing the code ranges in which the authentication_timeout interrupt is enabled. For the moment, though, this is a cheap and reasonably noninvasive fix for a field-reported failure; the other approach would be complex and not necessarily bug-free itself. Back-patch to all supported branches.
Avoid transaction-commit race condition while receiving a NOTIFY message.
commit : 7bfdf10f5aa33b9878a24d618dca75e9f60255d9 author : Tom Lane <email@example.com> date : Thu, 13 Mar 2014 12:03:03 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Thu, 13 Mar 2014 12:03:03 -0400
Use TransactionIdIsInProgress, then TransactionIdDidCommit, to distinguish whether a NOTIFY message's originating transaction is in progress, committed, or aborted. The previous coding could accept a message from a transaction that was still in-progress according to the PGPROC array; if the client were fast enough at starting a new transaction, it might fail to see table rows added/updated by the message-sending transaction. Which of course would usually be the point of receiving the message. We noted this type of race condition long ago in tqual.c, but async.c overlooked it. The race condition probably cannot occur unless there are multiple NOTIFY senders in action, since an individual backend doesn't send NOTIFY signals until well after it's done committing. But if two senders commit in close succession, it's certainly possible that we could see the second sender's message within the race condition window while responding to the signal from the first one. Per bug #9557 from Marko Tiikkaja. This patch is slightly more invasive than what he proposed, since it removes the now-redundant TransactionIdDidAbort call. Back-patch to 9.0, where the current NOTIFY implementation was introduced.
In WAL replay, restore GIN metapage unconditionally to avoid torn page.
commit : 63e59c25961f14763d86a44d8e2eccafaa337d75 author : Heikki Linnakangas <email@example.com> date : Wed, 12 Mar 2014 09:59:49 +0200 committer: Heikki Linnakangas <firstname.lastname@example.org> date : Wed, 12 Mar 2014 09:59:49 +0200
We don't take a full-page image of the GIN metapage; instead, the WAL record contains all the information required to reconstruct it from scratch. But to avoid torn page hazards, we must re-initialize it from the WAL record every time, even if it already has a greater LSN, similar to how normal full page images are restored. This was highly unlikely to cause any problems in practice, because the GIN metapage is small. We rely on an update smaller than a 512 byte disk sector to be atomic elsewhere, at least in pg_control. But better safe than sorry, and this would be easy to overlook if more fields are added to the metapage so that it's no longer small. Reported by Noah Misch. Backpatch to all supported versions.
Fix dangling smgr_owner pointer when a fake relcache entry is freed.
commit : 080ad9120d79933e5aed545986885058f8aa7385 author : Heikki Linnakangas <email@example.com> date : Fri, 7 Mar 2014 13:25:11 +0200 committer: Heikki Linnakangas <firstname.lastname@example.org> date : Fri, 7 Mar 2014 13:25:11 +0200
A fake relcache entry can "own" a SmgrRelation object, like a regular relcache entry. But when it was free'd, the owner field in SmgrRelation was not cleared, so it was left pointing to free'd memory. Amazingly this apparently hasn't caused crashes in practice, or we would've heard about it earlier. Andres found this with Valgrind. Report and fix by Andres Freund, with minor modifications by me. Backpatch to all supported versions.
Avoid memcpy() with same source and destination address.
commit : c7a186e392d4654148a45eaf8ffbf026553ecbdb author : Heikki Linnakangas <email@example.com> date : Fri, 7 Mar 2014 13:13:33 +0200 committer: Heikki Linnakangas <firstname.lastname@example.org> date : Fri, 7 Mar 2014 13:13:33 +0200
The behavior of that is undefined, although unlikely to lead to problems in practice. Found by running regression tests with Valgrind.
Fix name of syslog_ident GUC in docs.
commit : ff2e0e1f96ae412d06d0d10551161ca027d897fd author : Heikki Linnakangas <email@example.com> date : Fri, 7 Mar 2014 10:35:37 +0200 committer: Heikki Linnakangas <firstname.lastname@example.org> date : Fri, 7 Mar 2014 10:35:37 +0200
Avoid getting more than AccessShareLock when deparsing a query.
commit : f3e3f6c5ba061ca8228649a5b9c0faa3d0ff4121 author : Tom Lane <email@example.com> date : Thu, 6 Mar 2014 19:31:16 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Thu, 6 Mar 2014 19:31:16 -0500
In make_ruledef and get_query_def, we have long used AcquireRewriteLocks to ensure that the querytree we are about to deparse is up-to-date and the schemas of the underlying relations aren't changing. Howwever, that function thinks the query is about to be executed, so it acquires locks that are stronger than necessary for the purpose of deparsing. Thus for example, if pg_dump asks to deparse a rule that includes "INSERT INTO t", we'd acquire RowExclusiveLock on t. That results in interference with concurrent transactions that might for example ask for ShareLock on t. Since pg_dump is documented as being purely read-only, this is unexpected. (Worse, it used to actually be read-only; this behavior dates back only to 8.1, cf commit ba4200246.) Fix this by adding a parameter to AcquireRewriteLocks to tell it whether we want the "real" execution locks or only AccessShareLock. Report, diagnosis, and patch by Dean Rasheed. Back-patch to all supported branches.
Fix lastReplayedEndRecPtr calculation when starting from shutdown checkpoint.
commit : 7552d3d1aba33198141f4953379f819df23988cf author : Heikki Linnakangas <email@example.com> date : Wed, 5 Mar 2014 13:27:18 +0200 committer: Heikki Linnakangas <firstname.lastname@example.org> date : Wed, 5 Mar 2014 13:27:18 +0200
When entering crash recovery followed by archive recovery, and the latest checkpoint is a shutdown checkpoint, and there are no more WAL records to replay before transitioning from crash to archive recovery, we would not immediately allow read-only connections in hot standby mode even if we could. That's because when starting from a shutdown checkpoint, we set lastReplayedEndRecPtr incorrectly to the record before the checkpoint record, instead of the checkpoint record itself. We don't run the redo routine of the shutdown checkpoint record, but starting recovery from it goes through the same motions, so it should be considered as replayed. Reported by Kyotaro HORIGUCHI. All versions with hot standby are affected, so backpatch to 9.0.
Allow regex operations to be terminated early by query cancel requests.
commit : a9eb4924a581282abbb80b26396db08f9fb15f57 author : Tom Lane <email@example.com> date : Sat, 1 Mar 2014 15:21:07 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Sat, 1 Mar 2014 15:21:07 -0500
The regex code didn't have any provision for query cancel; which is unsurprising given its non-Postgres origin, but still problematic since some operations can take a long time. Introduce a callback function to check for a pending query cancel or session termination request, and call it in a couple of strategic spots where we can make the regex code exit with an error indicator. If we ever actually split out the regex code as a standalone library, some additional work will be needed to let the cancel callback function be specified externally to the library. But that's straightforward (certainly so by comparison to putting the locale-dependent character classification logic on a similar arms-length basis), and there seems no need to do it right now. A bigger issue is that there may be more places than these two where we need to check for cancels. We can always add more checks later, now that the infrastructure is in place. Since there are known examples of not-terribly-long regexes that can lock up a backend for a long time, back-patch to all supported branches. I have hopes of fixing the known performance problems later, but adding query cancel ability seems like a good idea even if they were all fixed.
Use SnapshotDirty rather than an active snapshot to probe index endpoints.
commit : 3e2db4c80bc631edfde57f8418551e2d5a79858f author : Tom Lane <email@example.com> date : Tue, 25 Feb 2014 16:04:16 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Tue, 25 Feb 2014 16:04:16 -0500
If there are lots of uncommitted tuples at the end of the index range, get_actual_variable_range() ends up fetching each one and doing an MVCC visibility check on it, until it finally hits a visible tuple. This is bad enough in isolation, considering that we don't need an exact answer only an approximate one. But because the tuples are not yet committed, each visibility check does a TransactionIdIsInProgress() test, which involves scanning the ProcArray. When multiple sessions do this concurrently, the ensuing contention results in horrid performance loss. 20X overall throughput loss on not-too-complicated queries is easy to demonstrate in the back branches (though someone's made it noticeably less bad in HEAD). We can dodge the problem fairly effectively by using SnapshotDirty rather than a normal MVCC snapshot. This will cause the index probe to take uncommitted tuples as good, so that we incur only one tuple fetch and test even if there are many such tuples. The extent to which this degrades the estimate is debatable: it's possible the result is actually a more accurate prediction than before, if the endmost tuple has become committed by the time we actually execute the query being planned. In any case, it's not very likely that it makes the estimate a lot worse. SnapshotDirty will still reject tuples that are known committed dead, so we won't give bogus answers if an invalid outlier has been deleted but not yet vacuumed from the index. (Because btrees know how to mark such tuples dead in the index, we shouldn't have a big performance problem in the case that there are many of them at the end of the range.) This consideration motivates not using SnapshotAny, which was also considered as a fix. Note: the back branches were using SnapshotNow instead of an MVCC snapshot, but the problem and solution are the same. Per performance complaints from Bartlomiej Romanski, Josh Berkus, and others. Back-patch to 9.0, where the issue was introduced (by commit 40608e7f949fb7e4025c0ddd5be01939adc79eec).
Remove broken code that tried to handle OVERLAPS with a single argument.
commit : e6f7fe983e1b454d4ec9e73a29be49ab3caaf409 author : Tom Lane <email@example.com> date : Tue, 18 Feb 2014 12:44:30 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Tue, 18 Feb 2014 12:44:30 -0500
The SQL standard says that OVERLAPS should have a two-element row constructor on each side. The original coding of OVERLAPS support in our grammar attempted to extend that by allowing a single-element row constructor, which it internally duplicated ... or tried to, anyway. But that code has certainly not worked since our List infrastructure was rewritten in 2004, and I'm none too sure it worked before that. As it stands, it ends up building a List that includes itself, leading to assorted undesirable behaviors later in the parser. Even if it worked as intended, it'd be a bit evil because of the possibility of duplicate evaluation of a volatile function that the user had written only once. Given the lack of documentation, test cases, or complaints, let's just get rid of the idea and only support the standard syntax. While we're at it, improve the error cursor positioning for the wrong-number-of-arguments errors, and inline the makeOverlaps() function since it's only called in one place anyway. Per bug #9227 from Joshua Yanovski. Initial patch by Joshua Yanovski, extended a bit by me.
commit : 2eb60c52c1a7961b29b80143285d5a0249b8583f author : Peter Eisentraut <email@example.com> date : Mon, 17 Feb 2014 16:57:27 -0500 committer: Peter Eisentraut <firstname.lastname@example.org> date : Mon, 17 Feb 2014 16:57:27 -0500