commit : c47f643c49d1f56c388dd0e7405ed280cfa9d0b2 author : Tom Lane <[email protected]> date : Mon, 3 Dec 2012 15:19:35 -0500 committer: Tom Lane <[email protected]> date : Mon, 3 Dec 2012 15:19:35 -0500
Update release notes for 9.2.2, 9.1.7, 9.0.11, 8.4.15, 8.3.22.
commit : 86e006d9ed64db7ceafdc8365208139278c5da60 author : Tom Lane <[email protected]> date : Mon, 3 Dec 2012 15:10:10 -0500 committer: Tom Lane <[email protected]> date : Mon, 3 Dec 2012 15:10:10 -0500
Revert "Add mode where contrib installcheck runs each module in a separately named database."
commit : 13632b0c14cca224a03c2ed76933d0700579dd8a author : Andrew Dunstan <[email protected]> date : Mon, 3 Dec 2012 15:03:15 -0500 committer: Andrew Dunstan <[email protected]> date : Mon, 3 Dec 2012 15:03:15 -0500
This reverts commit 513e546a6e75b0a79c3102ce22c583ccd1053ac6.
Avoid holding vmbuffer pin after VACUUM. During VACUUM if we pause to perform a cycle of index cleanup we drop the vmbuffer pin, so we should do the same thing when heap scan completes. This avoids holding vmbuffer pin across the main index cleanup in VACUUM, which could be minutes or hours longer than necessary for correctness.
commit : 3c4eec4488fef07675db85e73445f410dac732dd author : Simon Riggs <[email protected]> date : Mon, 3 Dec 2012 18:55:42 +0000 committer: Simon Riggs <[email protected]> date : Mon, 3 Dec 2012 18:55:42 +0000
Bug report and suggested fix from Pavan Deolasee
Fix documentation of path(polygon) function.
commit : e0aad34a6b1afa4fc165849d2743f769e550f022 author : Tom Lane <[email protected]> date : Mon, 3 Dec 2012 11:08:59 -0500 committer: Tom Lane <[email protected]> date : Mon, 3 Dec 2012 11:08:59 -0500
Obviously, this returns type "path", but somebody made a copy-and-pasteo long ago. Dagfinn Ilmari Mannsåker
commit : 04a210b090ee9ff3ff4c148c07dff62eb4c30f92 author : Peter Eisentraut <[email protected]> date : Mon, 3 Dec 2012 07:53:51 -0500 committer: Peter Eisentraut <[email protected]> date : Mon, 3 Dec 2012 07:53:51 -0500
Add mode where contrib installcheck runs each module in a separately named database.
commit : 513e546a6e75b0a79c3102ce22c583ccd1053ac6 author : Andrew Dunstan <[email protected]> date : Sun, 2 Dec 2012 17:29:30 -0500 committer: Andrew Dunstan <[email protected]> date : Sun, 2 Dec 2012 17:29:30 -0500
Normally each module is tested in aq database named contrib_regression, which is dropped and recreated at the beginhning of each pg_regress run. This mode, enabled by adding USE_MODULE_DB=1 to the make command line, runs most modules in a database with the module name embedded in it. This will make testing pg_upgrade on clusters with the contrib modules a lot easier. Still to be done: adapt to the MSVC build system. Backpatch to 9.0, which is the earliest version it is reasonably possible to test upgrading from.
Update time zone data files to tzdata release 2012j.
commit : 31ab8936c770545d6aaa09d348661ce175f9b33d author : Tom Lane <[email protected]> date : Sun, 2 Dec 2012 16:35:23 -0500 committer: Tom Lane <[email protected]> date : Sun, 2 Dec 2012 16:35:23 -0500
DST law changes in Cuba, Israel, Jordan, Libya, Palestine, Western Samoa, and portions of Brazil.
Recommend triggers, not rules, in the CREATE VIEW reference page.
commit : 7e487c1b0acbb26a481e64570dcbfe39b3e54abb author : Tom Lane <[email protected]> date : Sun, 2 Dec 2012 16:17:53 -0500 committer: Tom Lane <[email protected]> date : Sun, 2 Dec 2012 16:17:53 -0500
We've generally recommended use of INSTEAD triggers over rules since that feature was added; but this old text in the CREATE VIEW reference page didn't get the memo. Noted by Thomas Kellerer.
Don't advance checkPoint.nextXid near the end of a checkpoint sequence.
commit : d08fd1f849ba7419b79094e6cf863b6c190784b5 author : Tom Lane <[email protected]> date : Sun, 2 Dec 2012 15:20:08 -0500 committer: Tom Lane <[email protected]> date : Sun, 2 Dec 2012 15:20:08 -0500
This reverts commit c11130690d6dca64267201a169cfb38c1adec5ef in favor of actually fixing the problem: namely, that we should never have been modifying the checkpoint record's nextXid at this point to begin with. The nextXid should match the state as of the checkpoint's logical WAL position (ie the redo point), not the state as of its physical position. It's especially bogus to advance it in some wal_levels and not others. In any case there is no need for the checkpoint record to carry the same nextXid shown in the XLOG_RUNNING_XACTS record just emitted by LogStandbySnapshot, as any replay operation will already have adopted that value as current. This fixes bug #7710 from Tarvi Pillessaar, and probably also explains bug #6291 from Daniel Farina, in that if a checkpoint were in progress at the instant of XID wraparound, the epoch bump would be lost as reported. (And, of course, these days there's at least a 50-50 chance of a checkpoint being in progress at any given instant.) Diagnosed by me and independently by Andres Freund. Back-patch to all branches supporting hot standby.
XidEpoch++ if wraparound during checkpoint. If wal_level = hot_standby we update the checkpoint nextxid, though in the case where a wraparound occurred half-way through a checkpoint we would neglect updating the epoch also. Updating the nextxid is arguably the wrong thing to do, but changing that may introduce subtle bugs into hot standby startup, while updating the value doesn't cause any known bugs yet. Minimal fix now to HEAD and backbranches, wider fix later in HEAD.
commit : 973c011639e1aecf7256de07e2aa8520f9b49035 author : Simon Riggs <[email protected]> date : Sun, 2 Dec 2012 15:01:44 +0000 committer: Simon Riggs <[email protected]> date : Sun, 2 Dec 2012 15:01:44 +0000
Bug reported in #6291 by Daniel Farina and slightly differently in Cause analysis and recommended fixes from Tom Lane and Andres Freund. Applied patch is minimal version of Andres Freund's work.
Fix psql crash while parsing SQL file whose encoding is different from client encoding and the client encoding is not *safe* one. Such an example is, file encoding is UTF-8 and client encoding SJIS. Patch contributed by Jiang Guiqing.
commit : a7c53092d88bf9c617713389bc11f0670762b723 author : Tatsuo Ishii <[email protected]> date : Sun, 2 Dec 2012 21:11:15 +0900 committer: Tatsuo Ishii <[email protected]> date : Sun, 2 Dec 2012 21:11:15 +0900
Prevent passing gmake's environment variables down through pg_regress.
commit : 647b1bcdfd26f786248366e4fb25c0fd62006329 author : Tom Lane <[email protected]> date : Sat, 1 Dec 2012 17:24:01 -0500 committer: Tom Lane <[email protected]> date : Sat, 1 Dec 2012 17:24:01 -0500
When we do "make install" to create a temp installation, we don't want that instance of make to try to communicate with any instance of make that might be calling us. This is known to cause problems if the upper make has a -jN flag, and in principle could cause problems even without that. Unset the relevant environment variables to prevent such issues. Andres Freund
Make sure sharedir/extension/ directory is created when needed.
commit : 04f91ae5d0caa5faae7100eac3b0ade6f84e1e9e author : Tom Lane <[email protected]> date : Sat, 1 Dec 2012 16:04:50 -0500 committer: Tom Lane <[email protected]> date : Sat, 1 Dec 2012 16:04:50 -0500
The previous coding worked as long as MODULEDIR wasn't set explicitly, because we create sharedir/$(datamoduledir) and the default value of that is "extension". But if some other value is specified for MODULEDIR then the installation directory needed for the control file wasn't made. Cédric Villemain
doc: Fix broken links to DocBook wiki
commit : 1b4359b55d8fe32a54460c3ea00567a2fafa6b9c author : Peter Eisentraut <[email protected]> date : Sat, 1 Dec 2012 01:52:23 -0500 committer: Peter Eisentraut <[email protected]> date : Sat, 1 Dec 2012 01:52:23 -0500
Take buffer lock while inspecting btree index pages in contrib/pageinspect.
commit : 2b96c32d5361f443b00d17bfbe1fc84dcdd6fbc0 author : Tom Lane <[email protected]> date : Fri, 30 Nov 2012 17:02:39 -0500 committer: Tom Lane <[email protected]> date : Fri, 30 Nov 2012 17:02:39 -0500
It's not safe to examine a shared buffer without any lock.
Add missing buffer lock acquisition in GetTupleForTrigger().
commit : df1aa462852309c6a3c53b81c296de61e7f5504c author : Tom Lane <[email protected]> date : Fri, 30 Nov 2012 13:56:04 -0500 committer: Tom Lane <[email protected]> date : Fri, 30 Nov 2012 13:56:04 -0500
If we had not been holding buffer pin continuously since the tuple was initially fetched by the UPDATE or DELETE query, it would be possible for VACUUM or a page-prune operation to move the tuple while we're trying to copy it. This would result in a garbage "old" tuple value being passed to an AFTER ROW UPDATE or AFTER ROW DELETE trigger. The preconditions for this are somewhat improbable, and the timing constraints are very tight; so it's not so surprising that this hasn't been reported from the field, even though the bug has been there a long time. Problem found by Andres Freund. Back-patch to all active branches.
Produce a more useful error message for over-length Unix socket paths.
commit : c6a91c92b51a13f204495851cf7a90e55ec16f0a author : Tom Lane <[email protected]> date : Thu, 29 Nov 2012 19:57:17 -0500 committer: Tom Lane <[email protected]> date : Thu, 29 Nov 2012 19:57:17 -0500
The length of a socket path name is constrained by the size of struct sockaddr_un, and there's not a lot we can do about it since that is a kernel API. However, it would be a good thing if we produced an intelligible error message when the user specifies a socket path that's too long --- and getaddrinfo's standard API is too impoverished to do this in the natural way. So insert explicit tests at the places where we construct a socket path name. Now you'll get an error that makes sense and even tells you what the limit is, rather than something generic like "Non-recoverable failure in name resolution". Per trouble report from Jeremy Drake and a fix idea from Andrew Dunstan.
Correctly init/deinit recovery xact environment. Previously we performed VirtualXactLockTableInsert but didn't set MyProc->lxid for Startup process. pg_locks now correctly shows "1/1" for vxid of Startup process during Hot Standby. At end of Hot Standby the Virtual Transaction was not deleted, leading to problems after promoting to normal running for some commands, such as CREATE INDEX CONCURRENTLY.
commit : 6f9a9da85c9015e773d12e8571c469e5a2a6b3fb author : Simon Riggs <[email protected]> date : Thu, 29 Nov 2012 23:52:17 +0000 committer: Simon Riggs <[email protected]> date : Thu, 29 Nov 2012 23:52:17 +0000
Fix assorted bugs in CREATE INDEX CONCURRENTLY.
commit : 1da5bef3174170a6768bea6621afcbf72dd02a87 author : Tom Lane <[email protected]> date : Thu, 29 Nov 2012 14:50:31 -0500 committer: Tom Lane <[email protected]> date : Thu, 29 Nov 2012 14:50:31 -0500
This patch changes CREATE INDEX CONCURRENTLY so that the pg_index flag changes it makes without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. This is a subset of a patch already applied in 9.2 and HEAD. Back-patch into all earlier supported branches. Tom Lane and Andres Freund
When processing nested structure pointer variables ecpg always expected an array datatype which of course is wrong.
commit : 381c3b8f4cba2d7d30d7010c28b06c076093876f author : Michael Meskes <[email protected]> date : Thu, 29 Nov 2012 17:12:00 +0100 committer: Michael Meskes <[email protected]> date : Thu, 29 Nov 2012 17:12:00 +0100
Applied patch by Muhammad Usama <[email protected]> to fix this.
Fix SELECT DISTINCT with index-optimized MIN/MAX on inheritance trees.
commit : bdceb861d7c8034f69ab07a11f2f2603d6d74b3e author : Tom Lane <[email protected]> date : Mon, 26 Nov 2012 12:57:30 -0500 committer: Tom Lane <[email protected]> date : Mon, 26 Nov 2012 12:57:30 -0500
In a query such as "SELECT DISTINCT min(x) FROM tab", the DISTINCT is pretty useless (there being only one output row), but nonetheless it shouldn't fail. But it could fail if "tab" is an inheritance parent, because planagg.c's code for fixing up equivalence classes after making the index-optimized MIN/MAX transformation wasn't prepared to find child-table versions of the aggregate expression. The least ugly fix seems to be to add an option to mutate_eclass_expressions() to skip child-table equivalence class members, which aren't used anymore at this stage of planning so it's not really necessary to fix them. Since child members are ignored in many cases already, it seems plausible for mutate_eclass_expressions() to have an option to ignore them too. Per bug #7703 from Maxim Boguk. Back-patch to 9.1. Although the same code exists before that, it cannot encounter child-table aggregates AFAICS, because the index optimization transformation cannot succeed on inheritance trees before 9.1 (for lack of MergeAppend).
pg_stat_replication.sync_state was displayed incorrectly at page boundary.
commit : 38b38fb12244c640230b1fd71d2c55ecc04844fa author : Heikki Linnakangas <[email protected]> date : Fri, 23 Nov 2012 18:51:51 +0200 committer: Heikki Linnakangas <[email protected]> date : Fri, 23 Nov 2012 18:51:51 +0200
XLogRecPtrIsInvalid() only checks the xrecoff field, which is correct when checking if a WAL record could legally begin at the given position, but WAL sending can legally be paused at a page boundary, in which case xrecoff is 0. Use XLByteEQ(..., InvalidXLogRecPtr) instead, which checks that both xlogid and xrecoff are 0. 9.3 doesn't have this problem because XLogRecPtr is now a single 64-bit integer, so XLogRecPtrIsInvalid() does the right thing. Apply to 9.2, and 9.1 where pg_stat_replication view was introduced. Kyotaro HORIGUCHI, reviewed by Fujii Masao.
Fix pg_resetxlog to use correct path to postmaster.pid.
commit : 806e6d1ddb90fcbc3b59b17434cafeb4af51c126 author : Tom Lane <[email protected]> date : Thu, 22 Nov 2012 11:23:33 -0500 committer: Tom Lane <[email protected]> date : Thu, 22 Nov 2012 11:23:33 -0500
Since we've already chdir'd into the data directory, the file should be referenced as just "postmaster.pid", without prefixing the directory path. This is harmless in the normal case where an absolute PGDATA path is used, but quite dangerous if a relative path is specified, since the program might then fail to notice an active postmaster. Reported by Hari Babu. This got broken in my commit eb5949d190e80360386113fde0f05854f0c9824d, so patch all active versions.
Avoid bogus "out-of-sequence timeline ID" errors in standby-mode.
commit : db3658b34faed7e247c9dc61e39a3a054c3cb5d8 author : Heikki Linnakangas <[email protected]> date : Thu, 22 Nov 2012 11:23:46 +0200 committer: Heikki Linnakangas <[email protected]> date : Thu, 22 Nov 2012 11:23:46 +0200
When startup process opens a WAL segment after replaying part of it, it validates the first page on the WAL segment, even though the page it's really interested in later in the file. As part of the validation, it checks that the TLI on the page header is >= the TLI it saw on the last page it read. If the segment contains a timeline switch, and we have already replayed it, and then re-open the WAL segment (because of streaming replication got disconnected and reconnected, for example), the TLI check will fail when the first page is validated. Fix that by relaxing the TLI check when re-opening a WAL segment. Backpatch to 9.0. Earlier versions had the same code, but before standby mode was introduced in 9.0, recovery never tried to re-read a segment after partially replaying it. Reported by Amit Kapila, while testing a new feature.
Don't launch new child processes after we've been told to shut down.
commit : 866f2dd78414c63a5fcd22ae3a36916e4da164b6 author : Tom Lane <[email protected]> date : Wed, 21 Nov 2012 15:18:47 -0500 committer: Tom Lane <[email protected]> date : Wed, 21 Nov 2012 15:18:47 -0500
Once we've received a shutdown signal (SIGINT or SIGTERM), we should not launch any more child processes, even if we get signals requesting such. The normal code path for spawning backends has always understood that, but the postmaster's infrastructure for hot standby and autovacuum didn't get the memo. As reported by Hari Babu in bug #7643, this could lead to failure to shut down at all in some cases, such as when SIGINT is received just before the startup process sends PMSIGNAL_RECOVERY_STARTED: we'd launch a bgwriter and checkpointer, and then those processes would have no idea that they ought to quit. Similarly, launching a new autovacuum worker would result in waiting till it finished before shutting down. Also, switch the order of the code blocks in reaper() that detect startup process crash versus shutdown termination. Once we've sent it a signal, we should not consider that exit(1) is surprising. This is just a cosmetic fix since shutdown occurs correctly anyway, but better not to log a phony complaint about startup process crash. Back-patch to 9.0. Some parts of this might be applicable before that, but given the lack of prior complaints I'm not going to worry too much about older branches.
Improve handling of INT_MIN / -1 and related cases.
commit : 4387cc9ab4ad7e037df32e93c8435e34b5832cc5 author : Tom Lane <[email protected]> date : Mon, 19 Nov 2012 21:21:40 -0500 committer: Tom Lane <[email protected]> date : Mon, 19 Nov 2012 21:21:40 -0500
Some platforms throw an exception for this division, rather than returning a necessarily-overflowed result. Since we were testing for overflow after the fact, an exception isn't nice. We can avoid the problem by treating division by -1 as negation. Add some regression tests so that we'll find out if any compilers try to optimize away the overflow check conditions. Back-patch of commit 1f7cb5c30983752ff8de833de30afcaee63536d0. Per discussion with Xi Wang, though this is different from the patch he submitted.
Limit values of archive_timeout, post_auth_delay, auth_delay.milliseconds.
commit : fe838e5074149058a1101092d3a557e4b86b8ff2 author : Tom Lane <[email protected]> date : Sun, 18 Nov 2012 17:15:16 -0500 committer: Tom Lane <[email protected]> date : Sun, 18 Nov 2012 17:15:16 -0500
The previous definitions of these GUC variables allowed them to range up to INT_MAX, but in point of fact the underlying code would suffer overflows or other errors with large values. Reduce the maximum values to something that won't misbehave. There's no apparent value in working harder than this, since very large delays aren't sensible for any of these. (Note: the risk with archive_timeout is that if we're late checking the state, the timestamp difference it's being compared to might overflow. So we need some amount of slop; the choice of INT_MAX/2 is arbitrary.) Per followup investigation of bug #7670. Although this isn't a very significant fix, might as well back-patch.
Fix the int8 and int2 cases of (minimum possible integer) % (-1).
commit : e9ad86ce6803faecda721311ff04dde88b38583b author : Tom Lane <[email protected]> date : Wed, 14 Nov 2012 17:30:07 -0500 committer: Tom Lane <[email protected]> date : Wed, 14 Nov 2012 17:30:07 -0500
The correct answer for this (or any other case with arg2 = -1) is zero, but some machines throw a floating-point exception instead of behaving sanely. Commit f9ac414c35ea084ff70c564ab2c32adb06d5296f dealt with this in int4mod, but overlooked the fact that it also happens in int8mod (at least on my Linux x86_64 machine). Protect int2mod as well; it's not clear whether any machines fail there (mine does not) but since the test is so cheap it seems better safe than sorry. While at it, simplify the original guard in int4mod: we need only check for arg2 == -1, we don't need to check arg1 explicitly. Xi Wang, with some editing by me.
Fix memory leaks in record_out() and record_send().
commit : 68a8ea6046a0583171a34269688a2bcd8d2f8f08 author : Tom Lane <[email protected]> date : Tue, 13 Nov 2012 14:44:40 -0500 committer: Tom Lane <[email protected]> date : Tue, 13 Nov 2012 14:44:40 -0500
record_out() leaks memory: it fails to free the strings returned by the per-column output functions, and also is careless about detoasted values. This results in a query-lifespan memory leakage when returning composite values to the client, because printtup() runs the output functions in the query-lifespan memory context. Fix it to handle these issues the same way printtup() does. Also fix a similar leakage in record_send(). (At some point we might want to try to run output functions in shorter-lived memory contexts, so that we don't need a zero-leakage policy for them. But that would be a significantly more invasive patch, which doesn't seem like material for back-patching.) In passing, use appendStringInfoCharMacro instead of appendStringInfoChar in the innermost data-copying loop of record_out, to try to shave a few cycles from this function's runtime. Per trouble report from Carlos Henrique Reimer. Back-patch to all supported versions.
Clarify docs on hot standby lock release
commit : d0d58f7aa94986edbab6c000470707b90ef37d54 author : Simon Riggs <[email protected]> date : Tue, 13 Nov 2012 15:58:05 -0300 committer: Simon Riggs <[email protected]> date : Tue, 13 Nov 2012 15:58:05 -0300
Andres Freund and Simon Riggs
Fix multiple problems in WAL replay.
commit : 634e148dcaa1ec77aba4f5eac883285e8f225268 author : Tom Lane <[email protected]> date : Mon, 12 Nov 2012 22:05:21 -0500 committer: Tom Lane <[email protected]> date : Mon, 12 Nov 2012 22:05:21 -0500
Most of the replay functions for WAL record types that modify more than one page failed to ensure that those pages were locked correctly to ensure that concurrent queries could not see inconsistent page states. This is a hangover from coding decisions made long before Hot Standby was added, when it was hardly necessary to acquire buffer locks during WAL replay at all, let alone hold them for carefully-chosen periods. The key problem was that RestoreBkpBlocks was written to hold lock on each page restored from a full-page image for only as long as it took to update that page. This was guaranteed to break any WAL replay function in which there was any update-ordering constraint between pages, because even if the nominal order of the pages is the right one, any mixture of full-page and non-full-page updates in the same record would result in out-of-order updates. Moreover, it wouldn't work for situations where there's a requirement to maintain lock on one page while updating another. Failure to honor an update ordering constraint in this way is thought to be the cause of bug #7648 from Daniel Farina: what seems to have happened there is that a btree page being split was rewritten from a full-page image before the new right sibling page was written, and because lock on the original page was not maintained it was possible for hot standby queries to try to traverse the page's right-link to the not-yet-existing sibling page. To fix, get rid of RestoreBkpBlocks as such, and instead create a new function RestoreBackupBlock that restores just one full-page image at a time. This function can be invoked by WAL replay functions at the points where they would otherwise perform non-full-page updates; in this way, the physical order of page updates remains the same no matter which pages are replaced by full-page images. We can then further adjust the logic in individual replay functions if it is necessary to hold buffer locks for overlapping periods. A side benefit is that we can simplify the handling of concurrency conflict resolution by moving that code into the record-type-specfic functions; there's no more need to contort the code layout to keep conflict resolution in front of the RestoreBkpBlocks call. In connection with that, standardize on zero-based numbering rather than one-based numbering for referencing the full-page images. In HEAD, I removed the macros XLR_BKP_BLOCK_1 through XLR_BKP_BLOCK_4. They are still there in the header files in previous branches, but are no longer used by the code. In addition, fix some other bugs identified in the course of making these changes: spgRedoAddNode could fail to update the parent downlink at all, if the parent tuple is in the same page as either the old or new split tuple and we're not doing a full-page image: it would get fooled by the LSN having been advanced already. This would result in permanent index corruption, not just transient failure of concurrent queries. Also, ginHeapTupleFastInsert's "merge lists" case failed to mark the old tail page as a candidate for a full-page image; in the worst case this could result in torn-page corruption. heap_xlog_freeze() was inconsistent about using a cleanup lock or plain exclusive lock: it did the former in the normal path but the latter for a full-page image. A plain exclusive lock seems sufficient, so change to that. Also, remove gistRedoPageDeleteRecord(), which has been dead code since VACUUM FULL was rewritten. Back-patch to 9.0, where hot standby was introduced. Note however that 9.0 had a significantly different WAL-logging scheme for GIST index updates, and it doesn't appear possible to make that scheme safe for concurrent hot standby queries, because it can leave inconsistent states in the index even between WAL records. Given the lack of complaints from the field, we won't work too hard on fixing that branch.
Check for stack overflow in transformSetOperationTree().
commit : f8ffe6234a09faeaabe034643b619462df897ca9 author : Tom Lane <[email protected]> date : Sun, 11 Nov 2012 19:56:21 -0500 committer: Tom Lane <[email protected]> date : Sun, 11 Nov 2012 19:56:21 -0500
Since transformSetOperationTree() recurses, it can be driven to stack overflow with enough UNION/INTERSECT/EXCEPT clauses in a query. Add a check to ensure it fails cleanly instead of crashing. Per report from Matthew Gerber (though it's not clear whether this is the only thing going wrong for him). Historical note: I think the reasoning behind not putting a check here in the beginning was that the check in transformExpr() ought to be sufficient to guard the whole parser. However, because transformSetOperationTree() recurses all the way to the bottom of the set-operation tree before doing any analysis of the statement's expressions, that check doesn't save it.
XSLT stylesheet: Add slash to directory name
commit : 1458f0f1dab91458bd4f4f731a64a7a52fe028d1 author : Peter Eisentraut <[email protected]> date : Thu, 8 Nov 2012 23:55:36 -0500 committer: Peter Eisentraut <[email protected]> date : Thu, 8 Nov 2012 23:55:36 -0500
Some versions of the XSLT stylesheets don't handle the missing slash correctly (they concatenate directory and file name without the slash). This might never have worked correctly.
Fix handling of inherited check constraints in ALTER COLUMN TYPE.
commit : f43ca3c8945fb60ed409b7768b0ce5ee0437161e author : Tom Lane <[email protected]> date : Mon, 5 Nov 2012 13:36:26 -0500 committer: Tom Lane <[email protected]> date : Mon, 5 Nov 2012 13:36:26 -0500
This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
Fix bogus handling of $(X) (i.e., ".exe") in isolationtester Makefile.
commit : efa81e3c946654f5d5b0a752def609416d32e056 author : Tom Lane <[email protected]> date : Thu, 1 Nov 2012 19:49:02 -0400 committer: Tom Lane <[email protected]> date : Thu, 1 Nov 2012 19:49:02 -0400
I'm not sure why commit 1eb1dde049ccfffc42c80c2bcec14155c58bcc1f seems to have made this start to fail on Cygwin when it never did before --- but nonetheless, the coding was pretty bogus, and unlike the way we handle $(X) anywhere else. Per buildfarm.
Document that TCP keepalive settings read as 0 on Unix-socket connections.
commit : c22acf455842765e08f58ee308a43882cfcc13d4 author : Tom Lane <[email protected]> date : Wed, 31 Oct 2012 14:26:20 -0400 committer: Tom Lane <[email protected]> date : Wed, 31 Oct 2012 14:26:20 -0400
Per bug #7631 from Rob Johnson. The code is operating as designed, but the docs didn't explain it.
Fix ALTER EXTENSION / SET SCHEMA
commit : 65225900de86044948c70e9732d02d99412eb171 author : Alvaro Herrera <[email protected]> date : Wed, 31 Oct 2012 10:49:14 -0300 committer: Alvaro Herrera <[email protected]> date : Wed, 31 Oct 2012 10:49:14 -0300
In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane
Prefer actual constants to pseudo-constants in equivalence class machinery.
commit : ff8f7103b559d8f19731157aca38650a938fedef author : Tom Lane <[email protected]> date : Fri, 26 Oct 2012 14:19:47 -0400 committer: Tom Lane <[email protected]> date : Fri, 26 Oct 2012 14:19:47 -0400
generate_base_implied_equalities_const() should prefer plain Consts over other em_is_const eclass members when choosing the "pivot" value that all the other members will be equated to. This makes it more likely that the generated equalities will be useful in constraint-exclusion proofs. Per report from Rushabh Lathia.
In pg_dump, dump SEQUENCE SET items in the data not pre-data section.
commit : 5110a96992e508b220a7a6ab303b0501c4237b4a author : Tom Lane <[email protected]> date : Fri, 26 Oct 2012 12:12:53 -0400 committer: Tom Lane <[email protected]> date : Fri, 26 Oct 2012 12:12:53 -0400
Represent a sequence's current value as a separate TableDataInfo dumpable object, so that it can be dumped within the data section of the archive rather than in pre-data. This fixes an undesirable inconsistency between the meanings of "--data-only" and "--section=data", and also fixes dumping of sequences that are marked as extension configuration tables, as per a report from Marko Kreen back in July. The main cost is that we do one more SQL query per sequence, but that's probably not very meaningful in most databases. Back-patch to 9.1, since it has the extension configuration issue even though not the --section switch.
Prevent parser from believing that views have system columns.
commit : f01936f70b58dec8136399f6258b37d762c3cec3 author : Tom Lane <[email protected]> date : Wed, 24 Oct 2012 14:53:58 -0400 committer: Tom Lane <[email protected]> date : Wed, 24 Oct 2012 14:53:58 -0400
Views should not have any pg_attribute entries for system columns. However, we forgot to remove such entries when converting a table to a view. This could lead to crashes later on, if someone attempted to reference such a column, as reported by Kohei KaiGai. This problem is corrected properly in HEAD (by removing the pg_attribute entries during conversion), but in the back branches we need to defend against existing mis-converted views. This fix costs us an extra syscache lookup per system column reference, which is annoying but probably not really measurable in the big scheme of things.
Fix hash_search to avoid corruption of the hash table on out-of-memory.
commit : d01a7442190686a981c0a5ce330e962d8083ac4f author : Tom Lane <[email protected]> date : Fri, 19 Oct 2012 15:24:15 -0400 committer: Tom Lane <[email protected]> date : Fri, 19 Oct 2012 15:24:15 -0400
An out-of-memory error during expand_table() on a palloc-based hash table would leave a partially-initialized entry in the table. This would not be harmful for transient hash tables, since they'd get thrown away anyway at transaction abort. But for long-lived hash tables, such as the relcache hash, this would effectively corrupt the table, leading to crash or other misbehavior later. To fix, rearrange the order of operations so that table enlargement is attempted before we insert a new entry, rather than after adding it to the hash table. Problem discovered by Hitoshi Harada, though this is a bit different from his proposed patch.
Fix ruleutils to print "INSERT INTO foo DEFAULT VALUES" correctly.
commit : 823f83d3d53ad2c0e799b1953ed9a1955840f11c author : Tom Lane <[email protected]> date : Fri, 19 Oct 2012 13:40:05 -0400 committer: Tom Lane <[email protected]> date : Fri, 19 Oct 2012 13:40:05 -0400
Per bug #7615 from Marko Tiikkaja. Apparently nobody ever tried this case before ...
Further tweaking of the readfile() function in pg_ctl.
commit : d2a5f326568dfe98559319db6f3b9d08f0c851cc author : Heikki Linnakangas <[email protected]> date : Thu, 18 Oct 2012 22:26:26 +0300 committer: Heikki Linnakangas <[email protected]> date : Thu, 18 Oct 2012 22:26:26 +0300
Don't leak a file descriptor if the file is empty or we can't read its size. Expect there to be a newline at the end of the last line, too. If there isn't, ignore anything after the last newline. This makes it a tiny bit more robust in case the file is appended to concurrently, so that we don't return the last line if it hasn't been fully written yet. And this makes the code a bit less obscure, anyway. Per Tom Lane's suggestion. Backpatch to all supported branches.
Fix planning of non-strict equivalence clauses above outer joins.
commit : 447dad7193721f757dddf7c409b0b75aa2b5fb98 author : Tom Lane <[email protected]> date : Thu, 18 Oct 2012 12:29:00 -0400 committer: Tom Lane <[email protected]> date : Thu, 18 Oct 2012 12:29:00 -0400
If a potential equivalence clause references a variable from the nullable side of an outer join, the planner needs to take care that derived clauses are not pushed to below the outer join; else they may use the wrong value for the variable. (The problem arises only with non-strict clauses, since if an upper clause can be proven strict then the outer join will get simplified to a plain join.) The planner attempted to prevent this type of error by checking that potential equivalence clauses aren't outerjoin-delayed as a whole, but actually we have to check each side separately, since the two sides of the clause will get moved around separately if it's treated as an equivalence. Bugs of this type can be demonstrated as far back as 7.4, even though releases before 8.3 had only a very ad-hoc notion of equivalence clauses. In addition, we neglected to account for the possibility that such clauses might have nonempty nullable_relids even when not outerjoin-delayed; so the equivalence-class machinery lacked logic to compute correct nullable_relids values for clauses it constructs. This oversight was harmless before 9.2 because we were only using RestrictInfo.nullable_relids for OR clauses; but as of 9.2 it could result in pushing constructed equivalence clauses to incorrect places. (This accounts for bug #7604 from Bill MacArthur.) Fix the first problem by adding a new test check_equivalence_delay() in distribute_qual_to_rels, and fix the second one by adding code in equivclass.c and called functions to set correct nullable_relids for generated clauses. Although I believe the second part of this is not currently necessary before 9.2, I chose to back-patch it anyway, partly to keep the logic similar across branches and partly because it seems possible we might find other reasons why we need valid values of nullable_relids in the older branches. Add regression tests illustrating these problems. In 9.0 and up, also add test cases checking that we can push constants through outer joins, since we've broken that optimization before and I nearly broke it again with an overly simplistic patch for this problem.
Close un-owned SMgrRelations at transaction end.
commit : 473320e6c87cc7ffc704b2823c685b3dd13c0342 author : Tom Lane <[email protected]> date : Wed, 17 Oct 2012 12:38:33 -0400 committer: Tom Lane <[email protected]> date : Wed, 17 Oct 2012 12:38:33 -0400
If an SMgrRelation is not "owned" by a relcache entry, don't allow it to live past transaction end. This design allows the same SMgrRelation to be used for blind writes of multiple blocks during a transaction, but ensures that we don't hold onto such an SMgrRelation indefinitely. Because an SMgrRelation typically corresponds to open file descriptors at the fd.c level, leaving it open when there's no corresponding relcache entry can mean that we prevent the kernel from reclaiming deleted disk space. (While CacheInvalidateSmgr messages usually fix that, there are cases where they're not issued, such as DROP DATABASE. We might want to add some more sinval messaging for that, but I'd be inclined to keep this type of logic anyway, since allowing VFDs to accumulate indefinitely for blind-written relations doesn't seem like a good idea.) This code replaces a previous attempt towards the same goal that proved to be unreliable. Back-patch to 9.1 where the previous patch was added.
Revert "Use "transient" files for blind writes, take 2".
commit : cacb65263b99c3d96aa4b250cdbda05072ade03e author : Tom Lane <[email protected]> date : Wed, 17 Oct 2012 12:37:20 -0400 committer: Tom Lane <[email protected]> date : Wed, 17 Oct 2012 12:37:20 -0400
This reverts commit fba105b1099f4f5fa7283bb17cba6fed2baa8d0c. That approach had problems with the smgr-level state not tracking what we really want to happen, and with the VFD-level state not tracking the smgr-level state very well either. In consequence, it was still possible to hold kernel file descriptors open for long-gone tables (as in recent report from Tore Halset), and yet there were also cases of FDs being closed undesirably soon. A replacement implementation will follow.
Fix typo in previous commit
commit : f34d1fa0c8bd587a165234e0971bba8dc5e1fd2a author : Simon Riggs <[email protected]> date : Wed, 17 Oct 2012 09:20:42 +0100 committer: Simon Riggs <[email protected]> date : Wed, 17 Oct 2012 09:20:42 +0100
Clarify hash index caution and copy to CREATE INDEX docs
commit : 3877b1fa17fc9003691d890cec5557c64db05462 author : Simon Riggs <[email protected]> date : Wed, 17 Oct 2012 08:27:27 +0100 committer: Simon Riggs <[email protected]> date : Wed, 17 Oct 2012 08:27:27 +0100
Fix race condition in pg_ctl reading postmaster.pid.
commit : 288367427472f3d300c51ff9941eb486cfc01c6a author : Heikki Linnakangas <[email protected]> date : Sat, 13 Oct 2012 12:48:14 +0300 committer: Heikki Linnakangas <[email protected]> date : Sat, 13 Oct 2012 12:48:14 +0300
If postmaster changed postmaster.pid while pg_ctl was reading it, pg_ctl could overrun the buffer it allocated for the file. Fix by reading the whole file to memory with one read() call. initdb contains an identical copy of the readfile() function, but the files that initdb reads are static, not modified concurrently. Nevertheless, add a simple bounds-check there, if only to silence static analysis tools. Per report from Dave Vitek. Backpatch to all supported branches.
Split up process latch initialization for more-fail-soft behavior.
commit : eb5e0d8488451bcfcf81e26fd82dd9687c99b941 author : Tom Lane <[email protected]> date : Sun, 14 Oct 2012 23:00:07 -0400 committer: Tom Lane <[email protected]> date : Sun, 14 Oct 2012 23:00:07 -0400
In the previous coding, new backend processes would attempt to create their self-pipe during the OwnLatch call in InitProcess. However, pipe creation could fail if the kernel is short of resources; and the system does not recover gracefully from a FATAL error right there, since we have armed the dead-man switch for this process and not yet set up the on_shmem_exit callback that would disarm it. The postmaster then forces an unnecessary database-wide crash and restart, as reported by Sean Chittenden. There are various ways we could rearrange the code to fix this, but the simplest and sanest seems to be to split out creation of the self-pipe into a new function InitializeLatchSupport, which must be called from a place where failure is allowed. For most processes that gets called in InitProcess or InitAuxiliaryProcess, but processes that don't call either but still use latches need their own calls. Back-patch to 9.1, which has only a part of the latch logic that 9.2 and HEAD have, but nonetheless includes this bug.
Fix cross-type case in partial row matching for hashed subplans.
commit : de31ea98a2c993cf1517f83112fc595f96f56b8a author : Tom Lane <[email protected]> date : Thu, 11 Oct 2012 12:21:09 -0400 committer: Tom Lane <[email protected]> date : Thu, 11 Oct 2012 12:21:09 -0400
When hashing a subplan like "WHERE (a, b) NOT IN (SELECT x, y FROM ...)", findPartialMatch() attempted to match rows using the hashtable's internal equality operators, which of course are for x and y's datatypes. What we need to use are the potentially cross-type operators for a=x, b=y, etc. Failure to do that leads to wrong answers or even crashes. The scope for problems is limited to cases where we have different types with compatible hash functions (else we'd not be using a hashed subplan), but for example int4 vs int8 can cause the problem. Per bug #7597 from Bo Jensen. This has been wrong since the hashed-subplan code was written, so patch all the way back.
Fix PGXS support for building loadable modules on AIX.
commit : bd0ef304f8a306522983f3b4b06274fdc45beed8 author : Tom Lane <[email protected]> date : Tue, 9 Oct 2012 21:04:15 -0400 committer: Tom Lane <[email protected]> date : Tue, 9 Oct 2012 21:04:15 -0400
Building a shlib on AIX requires use of the mkldexport.sh script, but we failed to install that, preventing its use from non-source-tree contexts. Also, Makefile.aix had the wrong idea about where to find the installed copy of the postgres.imp symbol file used by AIX. Per report from John Pierce. Patch all the way back, since this has been broken since the beginning of PGXS.
Fix lo_import and lo_export to return useful error messages more often.
commit : bb3aa7a484a53d80784c367e2ff272b8730e338d author : Tom Lane <[email protected]> date : Mon, 8 Oct 2012 21:52:48 -0400 committer: Tom Lane <[email protected]> date : Mon, 8 Oct 2012 21:52:48 -0400
I found that these functions tend to return -1 while leaving an empty error message string in the PGconn, if they suffer some kind of I/O error on the file. The reason is that lo_close, which thinks it's executed a perfectly fine SQL command, clears the errorMessage. The minimum-change workaround is to reorder operations here so that we don't fill the errorMessage until after lo_close.
Fix lo_export usage in example programs.
commit : a883c02449cf86a657838303213d11ad85939b1d author : Tom Lane <[email protected]> date : Mon, 8 Oct 2012 21:18:57 -0400 committer: Tom Lane <[email protected]> date : Mon, 8 Oct 2012 21:18:57 -0400
lo_export returns -1, not zero, on failure.
Say ANALYZE, not VACUUM, in error message on analyze in hot standby.
commit : 3c856708e56ceb7025066a800c95b7293e9bd3f5 author : Heikki Linnakangas <[email protected]> date : Mon, 8 Oct 2012 14:17:27 +0300 committer: Heikki Linnakangas <[email protected]> date : Mon, 8 Oct 2012 14:17:27 +0300
Removed sentence about not being able to retrieve more than one row at a time, because it is not correct.
commit : 8ebe8889a8c5604b66802508b822cf18b8cd6820 author : Michael Meskes <[email protected]> date : Fri, 5 Oct 2012 16:49:27 +0200 committer: Michael Meskes <[email protected]> date : Fri, 5 Oct 2012 16:49:27 +0200
Fixed test for array boundary.
commit : 856ce0fb563a630ddd07dfad8cb4d8eb1d601b77 author : Michael Meskes <[email protected]> date : Fri, 5 Oct 2012 16:37:45 +0200 committer: Michael Meskes <[email protected]> date : Fri, 5 Oct 2012 16:37:45 +0200
Instead of continuing if the next character is not an array boundary get_data() used to continue only on finding a boundary so it was not able to read any element after the first.
Fix permissions explanations in CREATE DATABASE and CREATE SCHEMA docs.
commit : 6c33084fa2eb1c1cce61def72d8eb7c91a69d525 author : Tom Lane <[email protected]> date : Thu, 4 Oct 2012 13:41:09 -0400 committer: Tom Lane <[email protected]> date : Thu, 4 Oct 2012 13:41:09 -0400
These reference pages still claimed that you have to be superuser to create a database or schema owned by a different role. That was true before 8.1, but it was changed in commits aa1110624c08298393dfce996f7b21809d98d3fd and f91370cd2faf1fd35a1ac74d84652a85ed841919 to allow assignment of ownership to any role you are a member of. However, at the time we were thinking of that primarily as a change to the ALTER OWNER rules, so the need to touch these two CREATE ref pages got missed.
REASSIGN OWNED: consider grants on tablespaces, too
commit : 412a4295b5390cfe4fd5b9fc84a25c6e2d1aa0ad author : Alvaro Herrera <[email protected]> date : Wed, 3 Oct 2012 12:22:41 -0300 committer: Alvaro Herrera <[email protected]> date : Wed, 3 Oct 2012 12:22:41 -0300
Apparently this was considered in the original code (see commit cec3b0a9) but I failed to notice that such entries would always be skipped by the database check at the start of the loop. Per bugs #7578 by Nikolay, #6116 by [email protected].
Fix access past end of string in date parsing.
commit : 6c00b2bbf7726efdf7d96ad5c9e9ef0450d2a150 author : Heikki Linnakangas <[email protected]> date : Tue, 2 Oct 2012 10:43:48 +0300 committer: Heikki Linnakangas <[email protected]> date : Tue, 2 Oct 2012 10:43:48 +0300
This affects date_in(), and a couple of other funcions that use DecodeDate(). Hitoshi Harada
Fix bugs in "restore.sql" script emitted in pg_dump tar output.
commit : d617b28c6cc315d1aa1a4855673dd9eb121dcf73 author : Tom Lane <[email protected]> date : Sat, 29 Sep 2012 17:56:50 -0400 committer: Tom Lane <[email protected]> date : Sat, 29 Sep 2012 17:56:50 -0400
The tar output module did some very ugly and ultimately incorrect hacking on COPY commands to try to get them to work in the context of restoring a deconstructed tar archive. In particular, it would fail altogether for table names containing any upper-case characters, since it smashed the command string to lower-case before modifying it (and, just to add insult to injury, did that in a way that would fail in multibyte encodings). I don't see any particular value in being flexible about the case of the command keywords, since the string will just have been created by dumpTableData, so let's get rid of the whole case-folding thing. Also, it doesn't seem to meet the POLA for the script to restore data only in COPY mode, so add \i commands to make it have comparable behavior in --inserts mode. Noted while looking at the tar-output code in connection with Brian Weaver's patch.
Fix tar files emitted by pg_basebackup to be POSIX conformant.
commit : dfa6eda5e44f1525aa6b142b8e252f5a79110ee6 author : Tom Lane <[email protected]> date : Fri, 28 Sep 2012 15:35:51 -0400 committer: Tom Lane <[email protected]> date : Fri, 28 Sep 2012 15:35:51 -0400
Back-patch portions of commit 05b555d12bc2ad0d581f48a12b45174db41dc10d. There doesn't seem to be any reason not to fix pg_basebackup fully, but we can't change pg_dump's "magic" string without breaking older versions of pg_restore. Instead, just patch pg_restore to accept either version of the magic string, in hopes of avoiding compatibility problems when 9.3 comes out. I also fixed pg_dump to write the correct 2-block EOF marker, since that won't create a compatibility problem with pg_restore and it could help with some versions of tar. Brian Weaver and Tom Lane
Fix examples of how to use "su" while starting the server.
commit : bc99397563ff88c31078d4bf66b8538c78a08bda author : Tom Lane <[email protected]> date : Tue, 25 Sep 2012 13:53:01 -0400 committer: Tom Lane <[email protected]> date : Tue, 25 Sep 2012 13:53:01 -0400
The syntax "su -c 'command' username" is not accepted by all versions of su, for example not OpenBSD's. More portable is "su username -c 'command'". So change runtime.sgml to recommend that syntax. Also, add a -D switch to the OpenBSD example script, for consistency with other examples. Per Denis Lapshin and Gábor Hidvégi.