commit : 6237fadcc95bdcadd760f893d7bd9b866fadfff3 author : Tom Lane <firstname.lastname@example.org> date : Mon, 17 Feb 2014 14:38:15 -0500 committer: Tom Lane <email@example.com> date : Mon, 17 Feb 2014 14:38:15 -0500
Last-minute updates for release notes.
commit : 4bde115e7e5177abcee018b136716e69f90738b5 author : Tom Lane <firstname.lastname@example.org> date : Mon, 17 Feb 2014 14:25:43 -0500 committer: Tom Lane <email@example.com> date : Mon, 17 Feb 2014 14:25:43 -0500
Add entries for security issues. Security: CVE-2014-0060 through CVE-2014-0067
Document risks of "make check" in the regression testing instructions.
commit : ff3d533e58c1842597660da9d21a902d971e2661 author : Tom Lane <firstname.lastname@example.org> date : Mon, 17 Feb 2014 11:24:42 -0500 committer: Tom Lane <email@example.com> date : Mon, 17 Feb 2014 11:24:42 -0500
Since the temporary server started by "make check" uses "trust" authentication, another user on the same machine could connect to it as database superuser, and then potentially exploit the privileges of the operating-system user who started the tests. We should change the testing procedures to prevent this risk; but discussion is required about the best way to do that, as well as more testing than is practical for an undisclosed security problem. Besides, the same issue probably affects some user-written test harnesses. So for the moment, we'll just warn people against using "make check" when there are untrusted users on the same machine. In passing, remove some ancient advice that suggested making the regression testing subtree world-writable if you'd built as root. That looks dangerously insecure in modern contexts, and anyway we should not be encouraging people to build Postgres as root. Security: CVE-2014-0067
Prevent potential overruns of fixed-size buffers.
commit : 655b665f745e2e07cf6936c6063b0250f5caa98f author : Tom Lane <firstname.lastname@example.org> date : Mon, 17 Feb 2014 11:20:27 -0500 committer: Tom Lane <email@example.com> date : Mon, 17 Feb 2014 11:20:27 -0500
Coverity identified a number of places in which it couldn't prove that a string being copied into a fixed-size buffer would fit. We believe that most, perhaps all of these are in fact safe, or are copying data that is coming from a trusted source so that any overrun is not really a security issue. Nonetheless it seems prudent to forestall any risk by using strlcpy() and similar functions. Fixes by Peter Eisentraut and Jozef Mlich based on Coverity reports. In addition, fix a potential null-pointer-dereference crash in contrib/chkpass. The crypt(3) function is defined to return NULL on failure, but chkpass.c didn't check for that before using the result. The main practical case in which this could be an issue is if libc is configured to refuse to execute unapproved hashing algorithms (e.g., "FIPS mode"). This ideally should've been a separate commit, but since it touches code adjacent to one of the buffer overrun changes, I included it in this commit to avoid last-minute merge issues. This issue was reported by Honza Horak. Security: CVE-2014-0065 for buffer overruns, CVE-2014-0066 for crypt()
Predict integer overflow to avoid buffer overruns.
commit : 12bbce15d93d7692ddff1405aa04b67f8a327f57 author : Noah Misch <firstname.lastname@example.org> date : Mon, 17 Feb 2014 09:33:31 -0500 committer: Noah Misch <email@example.com> date : Mon, 17 Feb 2014 09:33:31 -0500
Several functions, mostly type input functions, calculated an allocation size such that the calculation wrapped to a small positive value when arguments implied a sufficiently-large requirement. Writes past the end of the inadvertent small allocation followed shortly thereafter. Coverity identified the path_in() vulnerability; code inspection led to the rest. In passing, add check_stack_depth() to prevent stack overflow in related functions. Back-patch to 8.4 (all supported versions). The non-comment hstore changes touch code that did not exist in 8.4, so that part stops at 9.0. Noah Misch and Heikki Linnakangas, reviewed by Tom Lane. Security: CVE-2014-0064
Fix handling of wide datetime input/output.
commit : f416622be81d1320417bbc7892fd562cae0dba72 author : Noah Misch <firstname.lastname@example.org> date : Mon, 17 Feb 2014 09:33:31 -0500 committer: Noah Misch <email@example.com> date : Mon, 17 Feb 2014 09:33:31 -0500
Many server functions use the MAXDATELEN constant to size a buffer for parsing or displaying a datetime value. It was much too small for the longest possible interval output and slightly too small for certain valid timestamp input, particularly input with a long timezone name. The long input was rejected needlessly; the long output caused interval_out() to overrun its buffer. ECPG's pgtypes library has a copy of the vulnerable functions, which bore the same vulnerabilities along with some of its own. In contrast to the server, certain long inputs caused stack overflow rather than failing cleanly. Back-patch to 8.4 (all supported versions). Reported by Daniel Schüssler, reviewed by Tom Lane. Security: CVE-2014-0063
Avoid repeated name lookups during table and index DDL.
commit : 820ab11fbfd508fc75a39c43ad2c1b3e79c4982b author : Robert Haas <firstname.lastname@example.org> date : Mon, 17 Feb 2014 09:33:31 -0500 committer: Robert Haas <email@example.com> date : Mon, 17 Feb 2014 09:33:31 -0500
If the name lookups come to different conclusions due to concurrent activity, we might perform some parts of the DDL on a different table than other parts. At least in the case of CREATE INDEX, this can be used to cause the permissions checks to be performed against a different table than the index creation, allowing for a privilege escalation attack. This changes the calling convention for DefineIndex, CreateTrigger, transformIndexStmt, transformAlterTableStmt, CheckIndexCompatible (in 9.2 and newer), and AlterTable (in 9.1 and older). In addition, CheckRelationOwnership is removed in 9.2 and newer and the calling convention is changed in older branches. A field has also been added to the Constraint node (FkConstraint in 8.4). Third-party code calling these functions or using the Constraint node will require updating. Report by Andres Freund. Patch by Robert Haas and Andres Freund, reviewed by Tom Lane. Security: CVE-2014-0062
Document security implications of check_function_bodies.
commit : c38c3080cb43e78bd1d082ad1ec3ad2af89c2601 author : Noah Misch <firstname.lastname@example.org> date : Mon, 17 Feb 2014 09:33:31 -0500 committer: Noah Misch <email@example.com> date : Mon, 17 Feb 2014 09:33:31 -0500
Back-patch to 8.4 (all supported versions).
Prevent privilege escalation in explicit calls to PL validators.
commit : 1d701d28a796ea2d1a4d2be9e9ee06209eaea040 author : Noah Misch <firstname.lastname@example.org> date : Mon, 17 Feb 2014 09:33:31 -0500 committer: Noah Misch <email@example.com> date : Mon, 17 Feb 2014 09:33:31 -0500
The primary role of PL validators is to be called implicitly during CREATE FUNCTION, but they are also normal functions that a user can call explicitly. Add a permissions check to each validator to ensure that a user cannot use explicit validator calls to achieve things he could not otherwise achieve. Back-patch to 8.4 (all supported versions). Non-core procedural language extensions ought to make the same two-line change to their own validators. Andres Freund, reviewed by Tom Lane and Noah Misch. Security: CVE-2014-0061
Shore up ADMIN OPTION restrictions.
commit : 15a8f97b9d16aaf659f58c981242b9da591cf24c author : Noah Misch <firstname.lastname@example.org> date : Mon, 17 Feb 2014 09:33:31 -0500 committer: Noah Misch <email@example.com> date : Mon, 17 Feb 2014 09:33:31 -0500
Granting a role without ADMIN OPTION is supposed to prevent the grantee from adding or removing members from the granted role. Issuing SET ROLE before the GRANT bypassed that, because the role itself had an implicit right to add or remove members. Plug that hole by recognizing that implicit right only when the session user matches the current role. Additionally, do not recognize it during a security-restricted operation or during execution of a SECURITY DEFINER function. The restriction on SECURITY DEFINER is not security-critical. However, it seems best for a user testing his own SECURITY DEFINER function to see the same behavior others will see. Back-patch to 8.4 (all supported versions). The SQL standards do not conflate roles and users as PostgreSQL does; only SQL roles have members, and only SQL users initiate sessions. An application using PostgreSQL users and roles as SQL users and roles will never attempt to grant membership in the role that is the session user, so the implicit right to add or remove members will never arise. The security impact was mostly that a role member could revoke access from others, contrary to the wishes of his own grantor. Unapproved role member additions are less notable, because the member can still largely achieve that by creating a view or a SECURITY DEFINER function. Reviewed by Andres Freund and Tom Lane. Reported, independently, by Jonas Sundman and Noah Misch. Security: CVE-2014-0060
Release notes for 9.3.3, 9.2.7, 9.1.12, 9.0.16, 8.4.20.
commit : 9649892c330429b86751f8eb37182e31018134f7 author : Tom Lane <firstname.lastname@example.org> date : Sun, 16 Feb 2014 22:08:34 -0500 committer: Tom Lane <email@example.com> date : Sun, 16 Feb 2014 22:08:34 -0500
Ooops, forgot to remove solar87 and friends from src/timezone/Makefile.
commit : 8f46ea7dc9e991e86b513bbd3a8e98fb07c9b916 author : Tom Lane <firstname.lastname@example.org> date : Fri, 14 Feb 2014 23:20:08 -0500 committer: Tom Lane <email@example.com> date : Fri, 14 Feb 2014 23:20:08 -0500
Update time zone data files to tzdata release 2013i.
commit : 4f975b68bea1a72be3099a8eaff373df9577a002 author : Tom Lane <firstname.lastname@example.org> date : Fri, 14 Feb 2014 21:59:13 -0500 committer: Tom Lane <email@example.com> date : Fri, 14 Feb 2014 21:59:13 -0500
DST law changes in Jordan; historical changes in Cuba. Also, remove the zones Asia/Riyadh87, Asia/Riyadh88, and Asia/Riyadh89. Per the upstream announcement: The files solar87, solar88, and solar89 are no longer distributed. They were a negative experiment -- that is, a demonstration that tz data can represent solar time only with some difficulty and error. Their presence in the distribution caused confusion, as Riyadh civil time was generally not solar time in those years.
Update regression testing instructions.
commit : 21bfc74c2743d23cf0f424bb6908e3be818ec0e8 author : Tom Lane <firstname.lastname@example.org> date : Fri, 14 Feb 2014 16:50:28 -0500 committer: Tom Lane <email@example.com> date : Fri, 14 Feb 2014 16:50:28 -0500
This documentation never got the word about the existence of check-world or installcheck-world. Revise to recommend use of those, and document all the subsidiary test suites. Do some minor wordsmithing elsewhere, too. In passing, remove markup related to generation of plain-text regression test instructions, since we don't do that anymore. Back-patch to 9.1 where check-world was added. (installcheck-world exists in 9.0; but since check-world doesn't, this patch would need additional work to cover that branch, and it doesn't seem worth the effort.)
Suggest shell here-documents instead of psql -c for multiple commands.
commit : c40b2d59e0dbac5a5215c9e1e9f05b22fcae6f13 author : Tom Lane <firstname.lastname@example.org> date : Fri, 14 Feb 2014 12:54:46 -0500 committer: Tom Lane <email@example.com> date : Fri, 14 Feb 2014 12:54:46 -0500
The documentation suggested using "echo | psql", but not the often-superior alternative of a here-document. Also, be more direct about suggesting that people avoid -c for multiple commands. Per discussion.
Clean up error cases in psql's COPY TO STDOUT/FROM STDIN code.
commit : 2573f08a164bfccb804c46106c0988464dc28e51 author : Tom Lane <firstname.lastname@example.org> date : Thu, 13 Feb 2014 18:45:20 -0500 committer: Tom Lane <email@example.com> date : Thu, 13 Feb 2014 18:45:20 -0500
Adjust handleCopyOut() to stop trying to write data once it's failed one time. For typical cases such as out-of-disk-space or broken-pipe, additional attempts aren't going to do anything but waste time, and in any case clean truncation of the output seems like a better behavior than randomly dropping blocks in the middle. Also remove dubious (and misleadingly documented) attempt to force our way out of COPY_OUT state if libpq didn't do that. If we did have a situation like that, it'd be a bug in libpq and would be better fixed there, IMO. We can hope that commit fa4440f51628d692f077d54b8313aea31af087ea took care of any such problems, anyway. Also fix longstanding bug in handleCopyIn(): PQputCopyEnd() only supports a non-null errormsg parameter in protocol version 3, and will actively fail if one is passed in version 2. This would've made our attempts to get out of COPY_IN state after a failure into infinite loops when talking to pre-7.4 servers. Back-patch the COPY_OUT state change business back to 9.2 where it was introduced, and the other two fixes into all supported branches.
Fix length checking for Unicode identifiers containing escapes (U&"...").
commit : 8439ee415f4d8850806a7fb59cc7ce4dbb6ea2ed author : Tom Lane <firstname.lastname@example.org> date : Thu, 13 Feb 2014 14:24:49 -0500 committer: Tom Lane <email@example.com> date : Thu, 13 Feb 2014 14:24:49 -0500
We used the length of the input string, not the de-escaped string, as the trigger for NAMEDATALEN truncation. AFAICS this would only result in sometimes printing a phony truncation warning; but it's just luck that there was no worse problem, since we were violating the API spec for truncate_identifier(). Per bug #9204 from Joshua Yanovski. This has been wrong since the Unicode-identifier support was added, so back-patch to all supported branches.
Improve cross-references between minor version release notes.
commit : 22fce59aaf811714b3d7a0f760568336526b8619 author : Tom Lane <firstname.lastname@example.org> date : Wed, 12 Feb 2014 19:09:24 -0500 committer: Tom Lane <email@example.com> date : Wed, 12 Feb 2014 19:09:24 -0500
We have a practice of providing a "bread crumb" trail between the minor versions where the migration section actually tells you to do something. Historically that was just plain text, eg, "see the release notes for 9.2.4"; but if you're using a browser or PDF reader, it's a lot nicer if it's a live hyperlink. So use "<xref>" instead. Any argument against doing this vanished with the recent decommissioning of plain-text release notes. Vik Fearing
Improve text of stub HISTORY file.
commit : 4f33f039699bdd0e47ca0a2e7bc8158d02388684 author : Tom Lane <firstname.lastname@example.org> date : Wed, 12 Feb 2014 18:16:17 -0500 committer: Tom Lane <email@example.com> date : Wed, 12 Feb 2014 18:16:17 -0500
Per Peter Eisentraut.
Improve libpq's error recovery for connection loss during COPY.
commit : 58faeb82486e68980d48208abae3523f6b005fed author : Tom Lane <firstname.lastname@example.org> date : Wed, 12 Feb 2014 17:50:13 -0500 committer: Tom Lane <email@example.com> date : Wed, 12 Feb 2014 17:50:13 -0500
In pqSendSome, if the connection is already closed at entry, discard any queued output data before returning. There is no possibility of ever sending the data, and anyway this corresponds to what we'd do if we'd detected a hard error while trying to send(). This avoids possible indefinite bloat of the output buffer if the application keeps trying to send data (or even just keeps trying to do PQputCopyEnd, as psql indeed will). Because PQputCopyEnd won't transition out of PGASYNC_COPY_IN state until it's successfully queued the COPY END message, and pqPutMsgEnd doesn't distinguish a queuing failure from a pqSendSome failure, this omission allowed an infinite loop in psql if the connection closure occurred when we had at least 8K queued to send. It might be worth refactoring so that we can make that distinction, but for the moment the other changes made here seem to offer adequate defenses. To guard against other variants of this scenario, do not allow PQgetResult to return a PGRES_COPY_XXX result if the connection is already known dead. Make sure it returns PGRES_FATAL_ERROR instead. Per report from Stephen Frost. Back-patch to all active branches.
In XLogReadBufferExtended, don't assume P_NEW yields consecutive pages.
commit : bc7ab301a9d6f307e1b6cb7ea5638a6bb374aa6c author : Tom Lane <firstname.lastname@example.org> date : Wed, 12 Feb 2014 14:52:23 -0500 committer: Tom Lane <email@example.com> date : Wed, 12 Feb 2014 14:52:23 -0500
In a database that's not yet reached consistency, it's possible that some segments of a relation are not full-size but are not the last ones either. Because of the way smgrnblocks() works, asking for a new page with P_NEW will fill in the last not-full-size segment --- and if that makes it full size, the apparent EOF of the relation will increase by more than one page, so that the next P_NEW request will yield a page past the next consecutive one. This breaks the relation-extension logic in XLogReadBufferExtended, possibly allowing a page update to be applied to some page far past where it was intended to go. This appears to be the explanation for reports of table bloat on replication slaves compared to their masters, and probably explains some corrupted-slave reports as well. Fix the loop to check the page number it actually got, rather than merely Assert()'ing that dead reckoning got it to the desired place. AFAICT, there are no other places that make assumptions about exactly which page they'll get from P_NEW. Problem identified by Greg Stark, though this is not the same as his proposed patch. It's been like this for a long time, so back-patch to all supported branches.
Add missing include, required on some platforms
commit : efb425a6f767da9447403d83f8ceb089ded3959d author : Magnus Hagander <firstname.lastname@example.org> date : Wed, 12 Feb 2014 20:04:13 +0100 committer: Magnus Hagander <email@example.com> date : Wed, 12 Feb 2014 20:04:13 +0100
Noted by the buildfarm and Andres Freund
Kill pg_basebackup background process when exiting
commit : 0ae288d2dd7c0b6725feebbcf799a4d65e057d05 author : Magnus Hagander <firstname.lastname@example.org> date : Sun, 9 Feb 2014 13:10:14 +0100 committer: Magnus Hagander <email@example.com> date : Sun, 9 Feb 2014 13:10:14 +0100
If an error occurs in the foreground (backup) process of pg_basebackup, and we exit in a controlled way, the background process (streaming xlog process) would stay around and keep streaming.
Don't generate plain-text HISTORY and src/test/regress/README anymore.
commit : dd560510400e4cf545ac92a5d0270dde2e45c5dd author : Tom Lane <firstname.lastname@example.org> date : Mon, 10 Feb 2014 20:48:20 -0500 committer: Tom Lane <email@example.com> date : Mon, 10 Feb 2014 20:48:20 -0500
Providing this information as plain text was doubtless worth the trouble ten years ago, but it seems likely that hardly anyone reads it in this format anymore. And the effort required to maintain these files (in the form of extra-complex markup rules in the relevant parts of the SGML documentation) is significant. So, let's stop doing that and rely solely on the other documentation formats. Per discussion, the plain-text INSTALL instructions might still be worth their keep, so we continue to generate that file. Rather than remove HISTORY and src/test/regress/README from distribution tarballs entirely, replace them with simple stub files that tell the reader where to find the relevant documentation. This is mainly to avoid possibly breaking packaging recipes that expect these files to exist. Back-patch to all supported branches, because simplifying the markup requirements for release notes won't help much unless we do it in all branches.
Use memmove() instead of memcpy() for copying overlapping regions.
commit : f3807106b404c2e78961dd868adcb91d6d9ca6ee author : Heikki Linnakangas <firstname.lastname@example.org> date : Mon, 10 Feb 2014 09:55:14 +0200 committer: Heikki Linnakangas <email@example.com> date : Mon, 10 Feb 2014 09:55:14 +0200
In commit d2495f272cd164ff075bee5c4ce95aed11338a36, I fixed this bug in to_tsquery(), but missed the fact that plainto_tsquery() has the same bug.
Avoid printing uninitialized filename variable in verbose mode
commit : 165aa1da588abcbcf3494b38bc03cb0e46e8831b author : Magnus Hagander <firstname.lastname@example.org> date : Sun, 9 Feb 2014 11:54:33 +0100 committer: Magnus Hagander <email@example.com> date : Sun, 9 Feb 2014 11:54:33 +0100
When using verbose mode for pg_basebackup, in tar format sent to stdout, we'd print an unitialized buffer as the filename. Reported by Pontus Lundkvist
Fix *-qualification of named parameters in SQL-language functions.
commit : 888b5657049f56508645be4f5dd911b2c286438c author : Tom Lane <firstname.lastname@example.org> date : Mon, 3 Feb 2014 14:46:57 -0500 committer: Tom Lane <email@example.com> date : Mon, 3 Feb 2014 14:46:57 -0500
Given a composite-type parameter named x, "$1.*" worked fine, but "x.*" not so much. This has been broken since named parameter references were added in commit 9bff0780cf5be2193a5bad0d3df2dbe143085264, so patch back to 9.2. Per bug #9085 from Hardy Falk.
Fix makefile syntax.
commit : c07702995ab48284f730c1ebc9ae066ff14469d0 author : Andrew Dunstan <firstname.lastname@example.org> date : Sat, 1 Feb 2014 19:52:11 -0500 committer: Andrew Dunstan <email@example.com> date : Sat, 1 Feb 2014 19:52:11 -0500
Fix some wide-character bugs in the text-search parser.
commit : 8be095cea5971d90f59a07f9bf49c58204c6cb2b author : Tom Lane <firstname.lastname@example.org> date : Sat, 1 Feb 2014 18:27:01 -0500 committer: Tom Lane <email@example.com> date : Sat, 1 Feb 2014 18:27:01 -0500
In p_isdigit and other character class test functions generated by the p_iswhat macro, the code path for non-C locales with multibyte encodings contained a bogus pointer cast that would accidentally fail to malfunction if types wchar_t and wint_t have the same width. Apparently that is true on most platforms, but not on recent Cygwin releases. Remove the cast, as it seems completely unnecessary (I think it arose from a false analogy to the need to cast to unsigned char when dealing with the <ctype.h> functions). Per bug #8970 from Marco Atzeri. In the same functions, the code path for C locale with a multibyte encoding simply ANDed each wide character with 0xFF before passing it to the corresponding <ctype.h> function. This could result in false positive answers for some non-ASCII characters, so use a range test instead. Noted by me while investigating Marco's complaint. Also, remove some useless though not actually buggy maskings and casts in the hand-coded p_isalnum and p_isalpha functions, which evidently got tested a bit more carefully than the macro-generated functions.
commit : 7fe4e357d2e1f72ced069d2bb9562b4be2f4fdf5 author : Andrew Dunstan <firstname.lastname@example.org> date : Sat, 1 Feb 2014 16:30:18 -0500 committer: Andrew Dunstan <email@example.com> date : Sat, 1 Feb 2014 16:30:18 -0500
Fix some more bugs in signal handlers and process shutdown logic.
commit : 81b116d987a779de7c97f5fd415a7c8348b9afff author : Tom Lane <firstname.lastname@example.org> date : Sat, 1 Feb 2014 16:21:04 -0500 committer: Tom Lane <email@example.com> date : Sat, 1 Feb 2014 16:21:04 -0500
WalSndKill was doing things exactly backwards: it should first clear MyWalSnd (to stop signal handlers from touching MyWalSnd->latch), then disown the latch, and only then mark the WalSnd struct unused by clearing its pid field. Also, WalRcvSigUsr1Handler and worker_spi_sighup failed to preserve errno, which is surely a requirement for any signal handler. Per discussion of recent buildfarm failures. Back-patch as far as the relevant code exists.
Don't use deprecated dllwrap on Cygwin.
commit : fad443753eea7d33ac68b4a9582596d623b4793b author : Andrew Dunstan <firstname.lastname@example.org> date : Sat, 1 Feb 2014 16:13:46 -0500 committer: Andrew Dunstan <email@example.com> date : Sat, 1 Feb 2014 16:13:46 -0500
The preferred method is to use "cc -shared", and this allows binaries to be rebased if required, unlike dllwrap. Backpatch to 9.0 where we have buildfarm coverage. There are still some issues with Cygwin, especially modern Cygwin, but this helps us get closer to good support. Marco Atzeri.
Copy the libpq DLL to the bin directory on Mingw and Cygwin.
commit : 6e96d4db8ad13c8661ec032532c4c36ace81df95 author : Andrew Dunstan <firstname.lastname@example.org> date : Sat, 1 Feb 2014 15:16:18 -0500 committer: Andrew Dunstan <email@example.com> date : Sat, 1 Feb 2014 15:16:18 -0500
This has long been done by the MSVC build system, and has caused confusion in the past when programs like psql have failed to start because they can't find the DLL. If it's in the same directory as it now will be they will find it. Backpatch to all live branches.
Clear MyProc and MyProcSignalState before they become invalid.
commit : ebe334463e7e7305591099c2bfc51aa4f1a17505 author : Robert Haas <firstname.lastname@example.org> date : Fri, 31 Jan 2014 21:31:08 -0500 committer: Robert Haas <email@example.com> date : Fri, 31 Jan 2014 21:31:08 -0500
Evidence from buildfarm member crake suggests that the new test_shm_mq module is routinely crashing the server due to the arrival of a SIGUSR1 after the shared memory segment has been unmapped. Although processes using the new dynamic background worker facilities are more likely to receive a SIGUSR1 around this time, the problem is also possible on older branches, so I'm back-patching the parts of this change that apply to older branches as far as they apply. It's already generally the case that code checks whether these pointers are NULL before deferencing them, so the important thing is mostly to make sure that they do get set to NULL before they become invalid. But in master, there's one case in procsignal_sigusr1_handler that lacks a NULL guard, so add that. Patch by me; review by Tom Lane.
Fix potential coredump on bad locale value in pg_upgrade.
commit : 62acbdaae45505bfa49fa80c730d0b289cfb6c0b author : Tom Lane <firstname.lastname@example.org> date : Thu, 30 Jan 2014 18:10:06 -0500 committer: Tom Lane <email@example.com> date : Thu, 30 Jan 2014 18:10:06 -0500
Thinko in error report (and a typo in the message text, too). We're failing anyway, but it would be good to print something useful first. Noted while reviewing a patch to make pg_upgrade's locale code laxer.
Fix unsafe references to errno within error messaging logic.
commit : 3e71ce1e9ab73a829ae3ddbcd9b03e6673e39c3e author : Tom Lane <firstname.lastname@example.org> date : Wed, 29 Jan 2014 20:04:05 -0500 committer: Tom Lane <email@example.com> date : Wed, 29 Jan 2014 20:04:05 -0500
Various places were supposing that errno could be expected to hold still within an ereport() nest or similar contexts. This isn't true necessarily, though in some cases it accidentally failed to fail depending on how the compiler chanced to order the subexpressions. This class of thinko explains recent reports of odd failures on clang-built versions, typically missing or inappropriate HINT fields in messages. Problem identified by Christian Kruse, who also submitted the patch this commit is based on. (I fixed a few issues in his patch and found a couple of additional places with the same disease.) Back-patch as appropriate to all supported branches.
Fix bugs in PQhost().
commit : ea311bfdfdfc9aeae4c7ba18cfa875f4ad2e2345 author : Fujii Masao <firstname.lastname@example.org> date : Thu, 23 Jan 2014 23:01:06 +0900 committer: Fujii Masao <email@example.com> date : Thu, 23 Jan 2014 23:01:06 +0900
In the platform that doesn't support Unix-domain socket, when neither host nor hostaddr are specified, the default host 'localhost' is used to connect to the server and PQhost() must return that, but it didn't. This patch fixes PQhost() so that it returns the default host in that case. Also this patch fixes PQhost() so that it doesn't return Unix-domain socket directory path in the platform that doesn't support Unix-domain socket. Back-patch to all supported versions.
Allow type_func_name_keywords in even more places
commit : c0e6169e16a84a55f6b3c1f802fe74004cc81592 author : Stephen Frost <firstname.lastname@example.org> date : Tue, 21 Jan 2014 22:49:22 -0500 committer: Stephen Frost <email@example.com> date : Tue, 21 Jan 2014 22:49:22 -0500
A while back, 2c92edad48796119c83d7dbe6c33425d1924626d allowed type_func_name_keywords to be used in more places, including role identifiers. Unfortunately, that commit missed out on cases where name_list was used for lists-of-roles, eg: for DROP ROLE. This resulted in the unfortunate situation that you could CREATE a role with a type_func_name_keywords-allowed identifier, but not DROP it (directly- ALTER could be used to rename it to something which could be DROP'd). This extends allowing type_func_name_keywords to places where role lists can be used. Back-patch to 9.0, as 2c92edad48796119c83d7dbe6c33425d1924626d was.
Tweak parse location assignment for CURRENT_DATE and related constructs.
commit : 27ab1eb7e72924bc464d3fd1fd6c380e8ea34ac2 author : Tom Lane <firstname.lastname@example.org> date : Tue, 21 Jan 2014 16:34:35 -0500 committer: Tom Lane <email@example.com> date : Tue, 21 Jan 2014 16:34:35 -0500
All these constructs generate parse trees consisting of a Const and a run-time type coercion (perhaps a FuncExpr or a CoerceViaIO). Modify the raw parse output so that we end up with the original token's location attached to the type coercion node while the Const has location -1; before, it was the other way around. This makes no difference in terms of what exprLocation() will say about the parse tree as a whole, so it should not have any user-visible impact. The point of changing it is that we do not want contrib/pg_stat_statements to treat these constructs as replaceable constants. It will do the right thing if the Const has location -1 rather than a valid location. This is a pretty ugly hack, but then this code is ugly already; we should someday replace this translation with special-purpose parse node(s) that would allow ruleutils.c to reconstruct the original query text. (See also commit 5d3fcc4c2e137417ef470d604fee5e452b22f6a7, which also hacked location assignment rules for the benefit of pg_stat_statements.) Back-patch to 9.2 where pg_stat_statements grew the ability to recognize replaceable constants. Kyotaro Horiguchi
Allow SET TABLESPACE to database default
commit : 1fe06595ab9124e47a6d7935e1796e7c31c03c1f author : Stephen Frost <firstname.lastname@example.org> date : Sat, 18 Jan 2014 18:41:52 -0500 committer: Stephen Frost <email@example.com> date : Sat, 18 Jan 2014 18:41:52 -0500
We've always allowed CREATE TABLE to create tables in the database's default tablespace without checking for CREATE permissions on that tablespace. Unfortunately, the original implementation of ALTER TABLE ... SET TABLESPACE didn't pick up on that exception. This changes ALTER TABLE ... SET TABLESPACE to allow the database's default tablespace without checking for CREATE rights on that tablespace, just as CREATE TABLE works today. Users could always do this through a series of commands (CREATE TABLE ... AS SELECT * FROM ...; DROP TABLE ...; etc), so let's fix the oversight in SET TABLESPACE's original implementation.
Fix client-only installation
commit : 526e38751a984ad2790246b5264a26c227ef0af8 author : Peter Eisentraut <firstname.lastname@example.org> date : Fri, 17 Jan 2014 23:08:22 -0500 committer: Peter Eisentraut <email@example.com> date : Fri, 17 Jan 2014 23:08:22 -0500
The psql Makefile was not creating $(datadir) before installing psqlrc.sample there. In most cases, the directory would be created in some other way, but for the documented from-source client-only installation procedure, it could fail. Reported-by: Mike Blackwell <firstname.lastname@example.org>
Improve FILES section of psql reference page.
commit : aa00af38c802b527338f0f14177c148a0cfed05c author : Tom Lane <email@example.com> date : Tue, 14 Jan 2014 19:27:57 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Tue, 14 Jan 2014 19:27:57 -0500
Primarily, explain where to find the system-wide psqlrc file, per recent gripe from John Sutton. Do some general wordsmithing and improve the markup, too. Also adjust psqlrc.sample so its comments about file location are somewhat trustworthy. (Not sure why we bother with this file when it's empty, but whatever.) Back-patch to 9.2 where the startup file naming scheme was last changed.
Fix multiple bugs in index page locking during hot-standby WAL replay.
commit : ad2e041a3f4b0d3266b0848c0da6eadce7391316 author : Tom Lane <email@example.com> date : Tue, 14 Jan 2014 17:34:54 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Tue, 14 Jan 2014 17:34:54 -0500
In ordinary operation, VACUUM must be careful to take a cleanup lock on each leaf page of a btree index; this ensures that no indexscans could still be "in flight" to heap tuples due to be deleted. (Because of possible index-tuple motion due to concurrent page splits, it's not enough to lock only the pages we're deleting index tuples from.) In Hot Standby, the WAL replay process must likewise lock every leaf page. There were several bugs in the code for that: * The replay scan might come across unused, all-zero pages in the index. While btree_xlog_vacuum itself did the right thing (ie, nothing) with such pages, xlogutils.c supposed that such pages must be corrupt and would throw an error. This accounts for various reports of replication failures with "PANIC: WAL contains references to invalid pages". To fix, add a ReadBufferMode value that instructs XLogReadBufferExtended not to complain when we're doing this. * btree_xlog_vacuum performed the extra locking if standbyState == STANDBY_SNAPSHOT_READY, but that's not the correct test: we won't open up for hot standby queries until the database has reached consistency, and we don't want to do the extra locking till then either, for fear of reading corrupted pages (which bufmgr.c would complain about). Fix by exporting a new function from xlog.c that will report whether we're actually in hot standby replay mode. * To ensure full coverage of the index in the replay scan, btvacuumscan would emit a dummy WAL record for the last page of the index, if no vacuuming work had been done on that page. However, if the last page of the index is all-zero, that would result in corruption of said page, since the functions called on it weren't prepared to handle that case. There's no need to lock any such pages, so change the logic to target the last normal leaf page instead. The first two of these bugs were diagnosed by Andres Freund, the other one by me. Fixes based on ideas from Heikki Linnakangas and myself. This has been wrong since Hot Standby was introduced, so back-patch to 9.0.
Fix possible buffer overrun in contrib/pg_trgm.
commit : 299498d6d11c851bab107313a4ca1bf2644881b6 author : Tom Lane <email@example.com> date : Mon, 13 Jan 2014 13:07:17 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 13 Jan 2014 13:07:17 -0500
Allow for the possibility that folding a string to lower case makes it longer (due to replacing a character with a longer multibyte character). This doesn't change the number of trigrams that will be extracted, but it does affect the required size of an intermediate buffer in generate_trgm(). Per bug #8821 from Ufuk Kayserilioglu. Also install some checks that the input string length is not so large as to cause overflow in the calculations of palloc request sizes. Back-patch to all supported versions.
Fix calculation of ISMN check digit.
commit : f6d6b42f2b1a9cbc5d1a8eb0c0d76eb27eecc0e2 author : Heikki Linnakangas <email@example.com> date : Mon, 13 Jan 2014 15:42:35 +0200 committer: Heikki Linnakangas <firstname.lastname@example.org> date : Mon, 13 Jan 2014 15:42:35 +0200
This has always been broken, so back-patch to all supported versions. Fabien COELHO
Fix possible crashes due to using elog/ereport too early in startup.
commit : 2de9051868f191719048e1d7a4addad6739a4a26 author : Tom Lane <email@example.com> date : Sat, 11 Jan 2014 16:35:34 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Sat, 11 Jan 2014 16:35:34 -0500
Per reports from Andres Freund and Luke Campbell, a server failure during set_pglocale_pgservice results in a segfault rather than a useful error message, because the infrastructure needed to use ereport hasn't been initialized; specifically, MemoryContextInit hasn't been called. One known cause of this is starting the server in a directory it doesn't have permission to read. We could try to prevent set_pglocale_pgservice from using anything that depends on palloc or elog, but that would be messy, and the odds of future breakage seem high. Moreover there are other things being called in main.c that look likely to use palloc or elog too --- perhaps those things shouldn't be there, but they are there today. The best solution seems to be to move the call of MemoryContextInit to very early in the backend's real main() function. I've verified that an elog or ereport occurring immediately after that is now capable of sending something useful to stderr. I also added code to elog.c to print something intelligible rather than just crashing if MemoryContextInit hasn't created the ErrorContext. This could happen if MemoryContextInit itself fails (due to malloc failure), and provides some future-proofing against someone trying to sneak in new code even earlier in server startup. Back-patch to all supported branches. Since we've only heard reports of this type of failure recently, it may be that some recent change has made it more likely to see a crash of this kind; but it sure looks like it's broken all the way back.
Fix compute_scalar_stats() for case that all values exceed WIDTH_THRESHOLD.
commit : f0381680fa480a8794d00566cef21178cd63d74e author : Tom Lane <email@example.com> date : Sat, 11 Jan 2014 13:41:41 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Sat, 11 Jan 2014 13:41:41 -0500
The standard typanalyze functions skip over values whose detoasted size exceeds WIDTH_THRESHOLD (1024 bytes), so as to limit memory bloat during ANALYZE. However, we (I think I, actually :-() failed to consider the possibility that *every* non-null value in a column is too wide. While compute_minimal_stats() seems to behave reasonably anyway in such a case, compute_scalar_stats() just fell through and generated no pg_statistic entry at all. That's unnecessarily pessimistic: we can still produce valid stanullfrac and stawidth values in such cases, since we do include too-wide values in the average-width calculation. Furthermore, since the general assumption in this code is that too-wide values are probably all distinct from each other, it seems reasonable to set stadistinct to -1 ("all distinct"). Per complaint from Kadri Raudsepp. This has been like this since roughly neolithic times, so back-patch to all supported branches.
Fix descriptor output in ECPG.
commit : 799728b0baa5b9f7c8dd6991808d1ed049e83b76 author : Michael Meskes <email@example.com> date : Thu, 9 Jan 2014 15:41:51 +0100 committer: Michael Meskes <firstname.lastname@example.org> date : Thu, 9 Jan 2014 15:41:51 +0100
While working on most platforms the old way sometimes created alignment problems. This should fix it. Also the regresion tests were updated to test for the reported case. Report and fix by MauMau <email@example.com>
Fix "cannot accept a set" error when only some arms of a CASE return a set.
commit : 97a39f295fd38a6083dfac96a0f1745f60ed5f9a author : Tom Lane <firstname.lastname@example.org> date : Wed, 8 Jan 2014 20:18:13 -0500 committer: Tom Lane <email@example.com> date : Wed, 8 Jan 2014 20:18:13 -0500
In commit c1352052ef1d4eeb2eb1d822a207ddc2d106cb13, I implemented an optimization that assumed that a function's argument expressions would either always return a set (ie multiple rows), or always not. This is wrong however: we allow CASE expressions in which some arms return a set of some type and others just return a scalar of that type. There may be other examples as well. To fix, replace the run-time test of whether an argument returned a set with a static precheck (expression_returns_set). This adds a little bit of query startup overhead, but it seems barely measurable. Per bug #8228 from David Johnston. This has been broken since 8.0, so patch all supported branches.
Fix pause_at_recovery_target + recovery_target_inclusive combination.
commit : 3bd8987ef88b8cf2c4c792ef5bbc46fc852e0f13 author : Heikki Linnakangas <firstname.lastname@example.org> date : Wed, 8 Jan 2014 23:06:03 +0200 committer: Heikki Linnakangas <email@example.com> date : Wed, 8 Jan 2014 23:06:03 +0200
If pause_at_recovery_target is set, recovery pauses *before* applying the target record, even if recovery_target_inclusive is set. If you then continue with pg_xlog_replay_resume(), it will apply the target record before ending recovery. In other words, if you log in while it's paused and verify that the database looks OK, ending recovery changes its state again, possibly destroying data that you were tring to salvage with PITR. Backpatch to 9.1, this has been broken since pause_at_recovery_target was added.
Fix bug in determining when recovery has reached consistency.
commit : 82c75f9dd3187d44d9fe2e335cd7460fc6d99b71 author : Heikki Linnakangas <firstname.lastname@example.org> date : Wed, 8 Jan 2014 11:39:55 +0200 committer: Heikki Linnakangas <email@example.com> date : Wed, 8 Jan 2014 11:39:55 +0200
When starting WAL replay from an online checkpoint, the last replayed WAL record variable was initialized using the checkpoint record's location, even though the records between the REDO location and the checkpoint record had not been replayed yet. That was noted as "slightly confusing" but harmless in the comment, but in some cases, it fooled CheckRecoveryConsistency to incorrectly conclude that we had already reached a consistent state immediately at the beginning of WAL replay. That caused the system to accept read-only connections in hot standby mode too early, and also PANICs with message "WAL contains references to invalid pages". Fix by initializing the variables to the REDO location instead. In 9.2 and above, change CheckRecoveryConsistency() to use lastReplayedEndRecPtr variable when checking if backup end location has been reached. It was inconsistently using EndRecPtr for that check, but lastReplayedEndRecPtr when checking min recovery point. It made no difference before this patch, because in all the places where CheckRecoveryConsistency was called the two variables were the same, but it was always an accident waiting to happen, and would have been wrong after this patch anyway. Report and analysis by Tomonari Katsumata, bug #8686. Backpatch to 9.0, where hot standby was introduced.
Update copyright for 2014
commit : 8aa6912b8fec3400441c365bde6a1030295de749 author : Bruce Momjian <firstname.lastname@example.org> date : Tue, 7 Jan 2014 16:05:29 -0500 committer: Bruce Momjian <email@example.com> date : Tue, 7 Jan 2014 16:05:29 -0500
Update all files in head, and files COPYRIGHT and legal.sgml in all back branches.
Move permissions check from do_pg_start_backup to pg_start_backup
commit : 61d4d14ee55534dd9fead189a5a339ecdf04e82a author : Magnus Hagander <firstname.lastname@example.org> date : Tue, 7 Jan 2014 17:47:52 +0100 committer: Magnus Hagander <email@example.com> date : Tue, 7 Jan 2014 17:47:52 +0100
And the same for do_pg_stop_backup. The code in do_pg_* is not allowed to access the catalogs. For manual base backups, the permissions check can be handled in the calling function, and for streaming base backups only users with the required permissions can get past the authentication step in the first place. Reported by Antonin Houska, diagnosed by Andres Freund
Avoid including tablespaces inside PGDATA twice in base backups
commit : 2edf3e82c5e23bf9095cab5c7c19578d46a13e48 author : Magnus Hagander <firstname.lastname@example.org> date : Tue, 7 Jan 2014 17:04:40 +0100 committer: Magnus Hagander <email@example.com> date : Tue, 7 Jan 2014 17:04:40 +0100
If a tablespace was crated inside PGDATA it was backed up both as part of the PGDATA backup and as the backup of the tablespace. Avoid this by skipping any directory inside PGDATA that contains one of the active tablespaces. Dimitri Fontaine and Magnus Hagander
Fix translatability markings in psql, and add defenses against future bugs.
commit : fa28f9cba889335ea68f9326010ae008f1d97b74 author : Tom Lane <firstname.lastname@example.org> date : Sat, 4 Jan 2014 16:05:23 -0500 committer: Tom Lane <email@example.com> date : Sat, 4 Jan 2014 16:05:23 -0500
Several previous commits have added columns to various \d queries without updating their translate_columns arrays, leading to potentially incorrect translations in NLS-enabled builds. Offenders include commit 893686762 (added prosecdef to \df+), c9ac00e6e (added description to \dc+) and 3b17efdfd (added description to \dC+). Fix those cases back to 9.3 or 9.2 as appropriate. Since this is evidently more easily missed than one would like, in HEAD also add an Assert that the supplied array is long enough. This requires an API change for printQuery(), so it seems inappropriate for back branches, but presumably all future changes will be tested in HEAD anyway. In HEAD and 9.3, also clean up a whole lot of sloppiness in the emitted SQL for \dy (event triggers): lack of translatability due to failing to pass words-to-be-translated through gettext_noop(), inadequate schema qualification, and sloppy formatting resulting in unnecessarily ugly -E output. Peter Eisentraut and Tom Lane, per bug #8702 from Sergey Burladyan
Do not use an empty hostname.
commit : 119a59879679289174460a777abc36c4f7944b37 author : Michael Meskes <firstname.lastname@example.org> date : Wed, 1 Jan 2014 12:24:19 +0100 committer: Michael Meskes <email@example.com> date : Wed, 1 Jan 2014 12:24:19 +0100
When trying to connect to a given database libecpg should not try using an empty hostname if no hostname was given.
Don't attempt to limit target database for pg_restore.
commit : df090b3908c8d1cd25bbb35068e7da3a2b4c5750 author : Kevin Grittner <firstname.lastname@example.org> date : Sun, 29 Dec 2013 15:18:38 -0600 committer: Kevin Grittner <email@example.com> date : Sun, 29 Dec 2013 15:18:38 -0600
There was an apparent attempt to limit the target database for pg_restore to version 7.1.0 or later. Due to a leading zero this was interpreted as an octal number, which allowed targets with version numbers down to 2.87.36. The lowest actual release above that was 6.0.0, so that was effectively the limit. Since the success of the restore attempt will depend primarily on on what statements were generated by the dump run, we don't want pg_restore trying to guess whether a given target should be allowed based on version number. Allow a connection to any version. Since it is very unlikely that anyone would be using a recent version of pg_restore to restore to a pre-6.0 database, this has little to no practical impact, but it makes the code less confusing to read. Issue reported and initial patch suggestion from Joel Jacobson based on an article by Andrey Karpov reporting on issues found by PVS-Studio static code analyzer. Final patch based on analysis by Tom Lane. Back-patch to all supported branches.
Properly detect invalid JSON numbers when generating JSON.
commit : 4825a9e95fbc11f2edcdd9dbaba08f10d257596f author : Andrew Dunstan <firstname.lastname@example.org> date : Fri, 27 Dec 2013 17:21:27 -0500 committer: Andrew Dunstan <email@example.com> date : Fri, 27 Dec 2013 17:21:27 -0500
Instead of looking for characters that aren't valid in JSON numbers, we simply pass the output string through the JSON number parser, and if it fails the string is quoted. This means among other things that money and domains over money will be quoted correctly and generate valid JSON. Fixes bug #8676 reported by Anderson Cristian da Silva. Backpatched to 9.2 where JSON generation was introduced.
Fix misplaced right paren bugs in pgstatfuncs.c.
commit : 150a30e19708d8181738c52723b82d783844b337 author : Kevin Grittner <firstname.lastname@example.org> date : Fri, 27 Dec 2013 15:41:02 -0600 committer: Kevin Grittner <email@example.com> date : Fri, 27 Dec 2013 15:41:02 -0600
The bug would only show up if the C sockaddr structure contained zero in the first byte for a valid address; otherwise it would fail to fail, which is probably why it went unnoticed for so long. Patch submitted by Joel Jacobson after seeing an article by Andrey Karpov in which he reports finding this through static code analysis using PVS-Studio. While I was at it I moved a definition of a local variable referenced in the buggy code to a more local context. Backpatch to all supported branches.
Add "SHIFT_JIS" as an accepted encoding name for locale checking.
commit : 0c07ef1ad2ba73a6a050f3e1a19267f961a43586 author : Tatsuo Ishii <firstname.lastname@example.org> date : Sun, 15 Dec 2013 10:33:06 +0900 committer: Tatsuo Ishii <email@example.com> date : Sun, 15 Dec 2013 10:33:06 +0900
When locale is "ja_JP.SJIS", nl_langinfo(CODESET) returns "SHIFT_JIS" on some platforms, at least on RedHat Linux. So the encoding/locale match table (encoding_match_list) needs the entry. Otherwise client encoding is set to SQL_ASCII. Back patch to all supported branches.
Fix inherited UPDATE/DELETE with UNION ALL subqueries.
commit : 5d545b7ed53a8b2058c1152bd1c9ae227b3280e3 author : Tom Lane <firstname.lastname@example.org> date : Sat, 14 Dec 2013 17:34:00 -0500 committer: Tom Lane <email@example.com> date : Sat, 14 Dec 2013 17:34:00 -0500
Fix an oversight in commit b3aaf9081a1a95c245fd605dcf02c91b3a5c3a29: we do indeed need to process the planner's append_rel_list when copying RTE subqueries, because if any of them were flattenable UNION ALL subqueries, the append_rel_list shows which subquery RTEs were pulled up out of which other ones. Without this, UNION ALL subqueries aren't correctly inserted into the update plans for inheritance child tables after the first one, typically resulting in no update happening for those child table(s). Per report from Victor Yegorov. Experimentation with this case also exposed a fault in commit a7b965382cf0cb30aeacb112572718045e6d4be7: if an inherited UPDATE/DELETE was proven totally dummy by constraint exclusion, we might arrive at add_rtes_to_flat_rtable with root->simple_rel_array being NULL. This should be interpreted as not having any RelOptInfos. I chose to code the guard as a check against simple_rel_array_size, so as to also provide some protection against indexing off the end of the array. Back-patch to 9.2 where the faulty code was added.
Add HOLD/RESUME_INTERRUPTS in HandleCatchupInterrupt/HandleNotifyInterrupt.
commit : d20eec82a0a07b9075154d1338dc6dc96ef8891c author : Tom Lane <firstname.lastname@example.org> date : Fri, 13 Dec 2013 14:05:19 -0500 committer: Tom Lane <email@example.com> date : Fri, 13 Dec 2013 14:05:19 -0500
This prevents a possible longjmp out of the signal handler if a timeout or SIGINT occurs while something within the handler has transiently set ImmediateInterruptOK. For safety we must hold off the timeout or cancel error until we're back in mainline, or at least till we reach the end of the signal handler when ImmediateInterruptOK was true at entry. This syncs these functions with the logic now present in handle_sig_alarm. AFAICT there is no live bug here in 9.0 and up, because I don't think we currently can wait for any heavyweight lock inside these functions, and there is no other code (except read-from-client) that will turn on ImmediateInterruptOK. However, that was not true pre-9.0: in older branches ProcessIncomingNotify might block trying to lock pg_listener, and then a SIGINT could lead to undesirable control flow. It might be all right anyway given the relatively narrow code ranges in which NOTIFY interrupts are enabled, but for safety's sake I'm back-patching this.
Fix ancient docs/comments thinko: XID comparison is mod 2^32, not 2^31.
commit : fcff4bd312bd70bfa01295a7c5e4db959ae105c8 author : Tom Lane <firstname.lastname@example.org> date : Thu, 12 Dec 2013 12:39:57 -0500 committer: Tom Lane <email@example.com> date : Thu, 12 Dec 2013 12:39:57 -0500
Pointed out by Gianni Ciolli.
Tweak placement of explicit ANALYZE commands in the regression tests.
commit : 9c9a1f2ebb00f96f1164f01006ab9861b36f1ab1 author : Tom Lane <firstname.lastname@example.org> date : Wed, 11 Dec 2013 15:08:38 -0500 committer: Tom Lane <email@example.com> date : Wed, 11 Dec 2013 15:08:38 -0500
Make the COPY test, which loads most of the large static tables used in the tests, also explicitly ANALYZE those tables. This allows us to get rid of various ad-hoc, and rather redundant, ANALYZE commands that had gotten stuck into various test scripts over time to ensure we got consistent plan choices. (We could have done a database-wide ANALYZE, but that would cause stats to get attached to the small static tables too, which results in plan changes compared to the historical behavior. I'm not sure that's a good idea, so not going that far for now.) Back-patch to 9.0, since 9.0 and 9.1 are currently sometimes failing regression tests for lack of an "ANALYZE tenk1" in the subselect test. There's no need for this in 8.4 since we didn't print any plans back then.
Fix possible crash with nested SubLinks.
commit : f5d9fdcc773c34992a9ebe867ed452a670b91d29 author : Tom Lane <firstname.lastname@example.org> date : Tue, 10 Dec 2013 16:10:24 -0500 committer: Tom Lane <email@example.com> date : Tue, 10 Dec 2013 16:10:24 -0500
An expression such as WHERE (... x IN (SELECT ...) ...) IN (SELECT ...) could produce an invalid plan that results in a crash at execution time, if the planner attempts to flatten the outer IN into a semi-join. This happens because convert_testexpr() was not expecting any nested SubLinks and would wrongly replace any PARAM_SUBLINK Params belonging to the inner SubLink. (I think the comment denying that this case could happen was wrong when written; it's certainly been wrong for quite a long time, since very early versions of the semijoin flattening logic.) Per report from Teodor Sigaev. Back-patch to all supported branches.
Fix performance regression in dblink connection speed.
commit : 7f4ef622f20733e46f00071b7ec9a9324169b9c2 author : Joe Conway <firstname.lastname@example.org> date : Sat, 7 Dec 2013 16:59:35 -0800 committer: Joe Conway <email@example.com> date : Sat, 7 Dec 2013 16:59:35 -0800
Previous commit e5de601267d98c5d60df6de8d436685c7105d149 modified dblink to ensure client encoding matched the server. However the added PQsetClientEncoding() call added significant overhead. Restore original performance in the common case where client encoding already matches server encoding by doing nothing in that case. Applies to all active branches. Issue reported and work sponsored by Zonar Systems.
Clear retry flags properly in replacement OpenSSL sock_write function.
commit : 41042970be02778c9fef4b3f7ed0c5c07adc8cc6 author : Tom Lane <firstname.lastname@example.org> date : Thu, 5 Dec 2013 12:48:35 -0500 committer: Tom Lane <email@example.com> date : Thu, 5 Dec 2013 12:48:35 -0500
Current OpenSSL code includes a BIO_clear_retry_flags() step in the sock_write() function. Either we failed to copy the code correctly, or they added this since we copied it. In any case, lack of the clear step appears to be the cause of the server lockup after connection loss reported in bug #8647 from Valentine Gogichashvili. Assume that this is correct coding for all OpenSSL versions, and hence back-patch to all supported branches. Diagnosis and patch by Alexander Kukushkin.
Fix full-page writes of internal GIN pages.
commit : 06df57ac6245f4495163bcad1316ec46444c73b3 author : Heikki Linnakangas <firstname.lastname@example.org> date : Tue, 3 Dec 2013 22:13:16 +0200 committer: Heikki Linnakangas <email@example.com> date : Tue, 3 Dec 2013 22:13:16 +0200
Insertion to a non-leaf GIN page didn't make a full-page image of the page, which is wrong. The code used to do it correctly, but was changed (commit 853d1c3103fa961ae6219f0281885b345593d101) because the redo-routine didn't track incomplete splits correctly when the page was restored from a full page image. Of course, that was not right way to fix it, the redo routine should've been fixed instead. The redo-routine was surreptitiously fixed in 2010 (commit 4016bdef8aded77b4903c457050622a5a1815c16), so all we need to do now is revert the code that creates the record to its original form. This doesn't change the format of the WAL record. Backpatch to all supported versions.
Fix crash in assign_collations_walker for EXISTS with empty SELECT list.
commit : 6698782f19d938a475c46922ac90e366713fc273 author : Tom Lane <firstname.lastname@example.org> date : Mon, 2 Dec 2013 20:28:53 -0500 committer: Tom Lane <email@example.com> date : Mon, 2 Dec 2013 20:28:53 -0500
We (I think I, actually) forgot about this corner case while coding collation resolution. Per bug #8648 from Arjen Nienhuis.