Skip to main content

Browse the archive

https://github.com/postgres/postgres
07 April 2024, 13:56:23 UTC
sort by:
Revision Author Date Message Commit Date
8c15a71 Tom Lane 02 February 2015, 20:46:01 UTC Stamp 9.0.19. 02 February 2015, 20:46:01 UTC
69ba47d Tom Lane 02 February 2015, 16:24:14 UTC Last-minute updates for release notes. Add entries for security issues. Security: CVE-2015-0241 through CVE-2015-0244 02 February 2015, 16:24:14 UTC
47ba0fb Heikki Linnakangas 02 February 2015, 15:09:17 UTC Be more careful to not lose sync in the FE/BE protocol. If any error occurred while we were in the middle of reading a protocol message from the client, we could lose sync, and incorrectly try to interpret a part of another message as a new protocol message. That will usually lead to an "invalid frontend message" error that terminates the connection. However, this is a security issue because an attacker might be able to deliberately cause an error, inject a Query message in what's supposed to be just user data, and have the server execute it. We were quite careful to not have CHECK_FOR_INTERRUPTS() calls or other operations that could ereport(ERROR) in the middle of processing a message, but a query cancel interrupt or statement timeout could nevertheless cause it to happen. Also, the V2 fastpath and COPY handling were not so careful. It's very difficult to recover in the V2 COPY protocol, so we will just terminate the connection on error. In practice, that's what happened previously anyway, as we lost protocol sync. To fix, add a new variable in pqcomm.c, PqCommReadingMsg, that is set whenever we're in the middle of reading a message. When it's set, we cannot safely ERROR out and continue running, because we might've read only part of a message. PqCommReadingMsg acts somewhat similarly to critical sections in that if an error occurs while it's set, the error handler will force the connection to be terminated, as if the error was FATAL. It's not implemented by promoting ERROR to FATAL in elog.c, like ERROR is promoted to PANIC in critical sections, because we want to be able to use PG_TRY/CATCH to recover and regain protocol sync. pq_getmessage() takes advantage of that to prevent an OOM error from terminating the connection. To prevent unnecessary connection terminations, add a holdoff mechanism similar to HOLD/RESUME_INTERRUPTS() that can be used hold off query cancel interrupts, but still allow die interrupts. The rules on which interrupts are processed when are now a bit more complicated, so refactor ProcessInterrupts() and the calls to it in signal handlers so that the signal handlers always call it if ImmediateInterruptOK is set, and ProcessInterrupts() can decide to not do anything if the other conditions are not met. Reported by Emil Lenngren. Patch reviewed by Noah Misch and Andres Freund. Backpatch to all supported versions. Security: CVE-2015-0244 02 February 2015, 15:09:25 UTC
0a3ee8a Noah Misch 02 February 2015, 15:00:45 UTC Cherry-pick security-relevant fixes from upstream imath library. This covers alterations to buffer sizing and zeroing made between imath 1.3 and imath 1.20. Valgrind Memcheck identified the buffer overruns and reliance on uninitialized data; their exploit potential is unknown. Builds specifying --with-openssl are unaffected, because they use the OpenSSL BIGNUM facility instead of imath. Back-patch to 9.0 (all supported versions). Security: CVE-2015-0243 02 February 2015, 15:00:52 UTC
ce6f261 Noah Misch 02 February 2015, 15:00:45 UTC Fix buffer overrun after incomplete read in pullf_read_max(). Most callers pass a stack buffer. The ensuing stack smash can crash the server, and we have not ruled out the viability of attacks that lead to privilege escalation. Back-patch to 9.0 (all supported versions). Marko Tiikkaja Security: CVE-2015-0243 02 February 2015, 15:00:52 UTC
9e05c50 Bruce Momjian 02 February 2015, 15:00:45 UTC port/snprintf(): fix overflow and do padding Prevent port/snprintf() from overflowing its local fixed-size buffer and pad to the desired number of digits with zeros, even if the precision is beyond the ability of the native sprintf(). port/snprintf() is only used on systems that lack a native snprintf(). Reported by Bruce Momjian. Patch by Tom Lane. Backpatch to all supported versions. Security: CVE-2015-0242 02 February 2015, 15:00:52 UTC
56b970f Bruce Momjian 02 February 2015, 15:00:45 UTC to_char(): prevent writing beyond the allocated buffer Previously very long localized month and weekday strings could overflow the allocated buffers, causing a server crash. Reported and patch reviewed by Noah Misch. Backpatch to all supported versions. Security: CVE-2015-0241 02 February 2015, 15:00:52 UTC
611e110 Bruce Momjian 02 February 2015, 15:00:44 UTC to_char(): prevent accesses beyond the allocated buffer Previously very long field masks for floats could access memory beyond the existing buffer allocated to hold the result. Reported by Andres Freund and Peter Geoghegan. Backpatch to all supported versions. Security: CVE-2015-0241 02 February 2015, 15:00:52 UTC
5828f7c Peter Eisentraut 02 February 2015, 03:56:09 UTC Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 8c8adccc355fb67d2a8690e4c830f8336b4f19a4 02 February 2015, 03:56:09 UTC
b09ca88 Peter Eisentraut 02 February 2015, 03:36:44 UTC doc: Improve claim about location of pg_service.conf The previous wording claimed that the file was always in /etc, but of course this varies with the installation layout. Write instead that it can be found via `pg_config --sysconfdir`. Even though this is still somewhat incorrect because it doesn't account of moved installations, it at least conveys that the location depends on the installation. 02 February 2015, 03:40:53 UTC
0e932ab Tom Lane 01 February 2015, 21:53:27 UTC Release notes for 9.4.1, 9.3.6, 9.2.10, 9.1.15, 9.0.19. 01 February 2015, 21:53:27 UTC
7238703 Tom Lane 31 January 2015, 23:35:34 UTC Fix documentation of psql's ECHO all mode. "ECHO all" is ignored for interactive input, and has been for a very long time, though possibly not for as long as the documentation has claimed the opposite. Fix that, and also note that empty lines aren't echoed, which while dubious is another longstanding behavior (it's embedded in our regression test files for one thing). Per bug #12721 from Hans Ginzel. In HEAD, also improve the code comments in this area, and suppress an unnecessary fflush(stdout) when we're not echoing. That would likely be safe to back-patch, but I'll not risk it mere hours before a release wrap. 31 January 2015, 23:35:34 UTC
3553d9c Tom Lane 31 January 2015, 03:45:44 UTC Update time zone data files to tzdata release 2015a. DST law changes in Chile and Mexico (state of Quintana Roo). Historical changes for Iceland. 31 January 2015, 03:46:22 UTC
7c41a32 Tom Lane 30 January 2015, 18:05:09 UTC Fix Coverity warning about contrib/pgcrypto's mdc_finish(). Coverity points out that mdc_finish returns a pointer to a local buffer (which of course is gone as soon as the function returns), leaving open a risk of misbehaviors possibly as bad as a stack overwrite. In reality, the only possible call site is in process_data_packets() which does not examine the returned pointer at all. So there's no live bug, but nonetheless the code is confusing and risky. Refactor to avoid the issue by letting process_data_packets() call mdc_finish() directly instead of going through the pullf_read() API. Although this is only cosmetic, it seems good to back-patch so that the logic in pgp-decrypt.c stays in sync across all branches. Marko Kreen 30 January 2015, 18:05:09 UTC
da8954b Stephen Frost 30 January 2015, 03:00:08 UTC Fix BuildIndexValueDescription for expressions In 804b6b6db4dcfc590a468e7be390738f9f7755fb we modified BuildIndexValueDescription to pay attention to which columns are visible to the user, but unfortunatley that commit neglected to consider indexes which are built on expressions. Handle error-reporting of violations of constraint indexes based on expressions by not returning any detail when the user does not have table-level SELECT rights. Backpatch to 9.0, as the prior commit was. Pointed out by Tom. 30 January 2015, 03:00:08 UTC
dc9a506 Tom Lane 30 January 2015, 01:18:46 UTC Handle unexpected query results, especially NULLs, safely in connectby(). connectby() didn't adequately check that the constructed SQL query returns what it's expected to; in fact, since commit 08c33c426bfebb32 it wasn't checking that at all. This could result in a null-pointer-dereference crash if the constructed query returns only one column instead of the expected two. Less excitingly, it could also result in surprising data conversion failures if the constructed query returned values that were not I/O-conversion-compatible with the types specified by the query calling connectby(). In all branches, insist that the query return at least two columns; this seems like a minimal sanity check that can't break any reasonable use-cases. In HEAD, insist that the constructed query return the types specified by the outer query, including checking for typmod incompatibility, which the code never did even before it got broken. This is to hide the fact that the implementation does a conversion to text and back; someday we might want to improve that. In back branches, leave that alone, since adding a type check in a minor release is more likely to break things than make people happy. Type inconsistencies will continue to work so long as the actual type and declared type are I/O representation compatible, and otherwise will fail the same way they used to. Also, in all branches, be on guard for NULL results from the constructed query, which formerly would cause null-pointer dereference crashes. We now print the row with the NULL but don't recurse down from it. In passing, get rid of the rather pointless idea that build_tuplestore_recursively() should return the same tuplestore that's passed to it. Michael Paquier, adjusted somewhat by me 30 January 2015, 01:18:46 UTC
059f30c Andres Freund 29 January 2015, 16:49:03 UTC Properly terminate the array returned by GetLockConflicts(). GetLockConflicts() has for a long time not properly terminated the returned array. During normal processing the returned array is zero initialized which, while not pretty, is sufficient to be recognized as a invalid virtual transaction id. But the HotStandby case is more than aesthetically broken: The allocated (and reused) array is neither zeroed upon allocation, nor reinitialized, nor terminated. Not having a terminating element means that the end of the array will not be recognized and that recovery conflict handling will thus read ahead into adjacent memory. Only terminating when hitting memory content that looks like a invalid virtual transaction id. Luckily this seems so far not have caused significant problems, besides making recovery conflict more expensive. Discussion: 20150127142713.GD29457@awork2.anarazel.de Backpatch into all supported branches. 29 January 2015, 21:48:46 UTC
3a20633 Stephen Frost 12 January 2015, 22:04:11 UTC Fix column-privilege leak in error-message paths While building error messages to return to the user, BuildIndexValueDescription and ri_ReportViolation would happily include the entire key or entire row in the result returned to the user, even if the user didn't have access to view all of the columns being included. Instead, include only those columns which the user is providing or which the user has select rights on. If the user does not have any rights to view the table or any of the columns involved then no detail is provided and a NULL value is returned from BuildIndexValueDescription. Note that, for key cases, the user must have access to all of the columns for the key to be shown; a partial key will not be returned. Back-patch all the way, as column-level privileges are now in all supported versions. This has been assigned CVE-2014-8161, but since the issue and the patch have already been publicized on pgsql-hackers, there's no point in trying to hide this commit. 28 January 2015, 17:33:29 UTC
8c418fb Tom Lane 26 January 2015, 17:18:25 UTC Fix volatile-safety issue in pltcl_SPI_execute_plan(). The "callargs" variable is modified within PG_TRY and then referenced within PG_CATCH, which is exactly the coding pattern we've now found to be unsafe. Marking "callargs" volatile would be problematic because it is passed by reference to some Tcl functions, so fix the problem by not modifying it within PG_TRY. We can just postpone the free() till we exit the PG_TRY construct, as is already done elsewhere in this same file. Also, fix failure to free(callargs) when exiting on too-many-arguments error. This is only a minor memory leak, but a leak nonetheless. In passing, remove some unnecessary "volatile" markings in the same function. Those doubtless are there because gcc 2.95.3 whinged about them, but we now know that its algorithm for complaining is many bricks shy of a load. This is certainly a live bug with compilers that optimize similarly to current gcc, so back-patch to all active branches. 26 January 2015, 17:18:55 UTC
93d7706 Tom Lane 26 January 2015, 16:57:47 UTC Fix volatile-safety issue in asyncQueueReadAllNotifications(). The "pos" variable is modified within PG_TRY and then referenced within PG_CATCH, so for strict POSIX conformance it must be marked volatile. Superficially the code looked safe because pos's address was taken, which was sufficient to force it into memory ... but it's not sufficient to ensure that the compiler applies updates exactly where the program text says to. The volatility marking has to extend into a couple of subroutines too, but I think that's probably a good thing because the risk of out-of-order updates is mostly in those subroutines not asyncQueueReadAllNotifications() itself. In principle the compiler could have re-ordered operations such that an error could be thrown while "pos" had an incorrect value. It's unclear how real the risk is here, but for safety back-patch to all active branches. 26 January 2015, 16:57:47 UTC
3a3ee65 Tom Lane 24 January 2015, 18:05:58 UTC Replace a bunch more uses of strncpy() with safer coding. strncpy() has a well-deserved reputation for being unsafe, so make an effort to get rid of nearly all occurrences in HEAD. A large fraction of the remaining uses were passing length less than or equal to the known strlen() of the source, in which case no null-padding can occur and the behavior is equivalent to memcpy(), though doubtless slower and certainly harder to reason about. So just use memcpy() in these cases. In other cases, use either StrNCpy() or strlcpy() as appropriate (depending on whether padding to the full length of the destination buffer seems useful). I left a few strncpy() calls alone in the src/timezone/ code, to keep it in sync with upstream (the IANA tzcode distribution). There are also a few such calls in ecpg that could possibly do with more analysis. AFAICT, none of these changes are more than cosmetic, except for the four occurrences in fe-secure-openssl.c, which are in fact buggy: an overlength source leads to a non-null-terminated destination buffer and ensuing misbehavior. These don't seem like security issues, first because no stack clobber is possible and second because if your values of sslcert etc are coming from untrusted sources then you've got problems way worse than this. Still, it's undesirable to have unpredictable behavior for overlength inputs, so back-patch those four changes to all active branches. 24 January 2015, 18:05:58 UTC
a113a66 Tom Lane 21 January 2015, 02:21:47 UTC Improve documentation of random() function. Move random() and setseed() to a separate table, to have them grouped together. Also add a notice that random() is not cryptographically secure. Back-patch of commit 75fdcec14543b60cc0c67483d8cc47d5c7adf1a8 into all supported versions, per discussion of the need to document that random() is just a wrapper around random(3). 21 January 2015, 02:21:47 UTC
338ff75 Tom Lane 20 January 2015, 04:44:33 UTC In pg_regress, remove the temporary installation upon successful exit. This results in a very substantial reduction in disk space usage during "make check-world", since that sequence involves creation of numerous temporary installations. It should also help a bit in the buildfarm, even though the buildfarm script doesn't create as many temp installations, because the current script misses deleting some of them; and anyway it seems better to do this once in one place rather than expecting that script to get it right every time. In 9.4 and HEAD, also undo the unwise choice in commit b1aebbb6a86e96d7 to report strerror(errno) after a rmtree() failure. rmtree has already reported that, possibly for multiple failures with distinct errnos; and what's more, by the time it returns there is no good reason to assume that errno still reflects the last reportable error. So reporting errno here is at best redundant and at worst badly misleading. Back-patch to all supported branches, so that future revisions of the buildfarm script can rely on this behavior. 20 January 2015, 04:44:33 UTC
a1a8d02 Tom Lane 20 January 2015, 04:01:46 UTC Adjust "pgstat wait timeout" message to be a translatable LOG message. Per discussion, change the log level of this message to be LOG not WARNING. The main point of this change is to avoid causing buildfarm run failures when the stats collector is exceptionally slow to respond, which it not infrequently is on some of the smaller/slower buildfarm members. This change does lose notice to an interactive user when his stats query is looking at out-of-date stats, but the majority opinion (not necessarily that of yours truly) is that WARNING messages would probably not get noticed anyway on heavily loaded production systems. A LOG message at least ensures that the problem is recorded somewhere where bulk auditing for the issue is possible. Also, instead of an untranslated "pgstat wait timeout" message, provide a translatable and hopefully more understandable message "using stale statistics instead of current ones because stats collector is not responding". The original text was written hastily under the assumption that it would never really happen in practice, which we now know to be unduly optimistic. Back-patch to all active branches, since we've seen the buildfarm issue in all branches. 20 January 2015, 04:01:46 UTC
cebb3f0 Peter Eisentraut 07 January 2015, 04:06:13 UTC Fix namespace handling in xpath function Previously, the xml value resulting from an xpath query would not have namespace declarations if the namespace declarations were attached to an ancestor element in the input xml value. That means the output value was not correct XML. Fix that by running the result value through xmlCopyNode(), which produces the correct namespace declarations. Author: Ali Akbar <the.apaan@gmail.com> 18 January 2015, 03:37:32 UTC
082764a Noah Misch 16 January 2015, 06:27:31 UTC Update "pg_regress --no-locale" for Darwin and Windows. Commit 894459e59ffa5c7fee297b246c17e1f72564db1d revealed this option to be broken for NLS builds on Darwin, but "make -C contrib/unaccent check" and the buildfarm client rely on it. Fix that configuration by redefining the option to imply LANG=C on Darwin. In passing, use LANG=C instead of LANG=en on Windows; since only postmaster startup uses that value, testers are unlikely to notice the change. Back-patch to 9.0, like the predecessor commit. 16 January 2015, 06:28:47 UTC
5308e08 Tom Lane 15 January 2015, 23:52:38 UTC Fix use-of-already-freed-memory problem in EvalPlanQual processing. Up to now, the "child" executor state trees generated for EvalPlanQual rechecks have simply shared the ResultRelInfo arrays used for the original execution tree. However, this leads to dangling-pointer problems, because ExecInitModifyTable() is all too willing to scribble on some fields of the ResultRelInfo(s) even when it's being run in one of those child trees. This trashes those fields from the perspective of the parent tree, because even if the generated subtree is logically identical to what was in use in the parent, it's in a memory context that will go away when we're done with the child state tree. We do however want to share information in the direction from the parent down to the children; in particular, fields such as es_instrument *must* be shared or we'll lose the stats arising from execution of the children. So the simplest fix is to make a copy of the parent's ResultRelInfo array, but not copy any fields back at end of child execution. Per report from Manuel Kniep. The added isolation test is based on his example. In an unpatched memory-clobber-enabled build it will reliably fail with "ctid is NULL" errors in all branches back to 9.1, as a consequence of junkfilter->jf_junkAttNo being overwritten with $7f7f. This test cannot be run as-is before that for lack of WITH syntax; but I have no doubt that some variant of this problem can arise in older branches, so apply the code change all the way back. 15 January 2015, 23:52:38 UTC
0a67c00 Robert Haas 15 January 2015, 14:26:03 UTC pg_standby: Avoid writing one byte beyond the end of the buffer. Previously, read() might have returned a length equal to the buffer length, and then the subsequent store to buf[len] would write a zero-byte one byte past the end. This doesn't seem likely to be a security issue, but there's some chance it could result in pg_standby misbehaving. Spotted by Coverity; patch by Michael Paquier, reviewed by me. 15 January 2015, 14:42:47 UTC
5b1e4c1 Tom Lane 12 January 2015, 20:13:45 UTC Avoid unexpected slowdown in vacuum regression test. I noticed the "vacuum" regression test taking really significantly longer than it used to on a slow machine. Investigation pointed the finger at commit e415b469b33ba328765e39fd62edcd28f30d9c3c, which added creation of an index using an extremely expensive index function. That function was evidently meant to be applied only twice ... but the test re-used an existing test table, which up till a couple lines before that had had over two thousand rows. Depending on timing of the concurrent regression tests, the intervening VACUUMs might have been unable to remove those recently-dead rows, and then the index build would need to create index entries for them too, leading to the wrap_do_analyze() function being executed 2000+ times not twice. Avoid this by using a different table that is guaranteed to have only the intended two rows in it. Back-patch to 9.0, like the commit that created the problem. 12 January 2015, 20:13:45 UTC
2e49461 Noah Misch 08 January 2015, 03:35:44 UTC On Darwin, detect and report a multithreaded postmaster. Darwin --enable-nls builds use a substitute setlocale() that may start a thread. Buildfarm member orangutan experienced BackendList corruption on account of different postmaster threads executing signal handlers simultaneously. Furthermore, a multithreaded postmaster risks undefined behavior from sigprocmask() and fork(). Emit LOG messages about the problem and its workaround. Back-patch to 9.0 (all supported versions). 08 January 2015, 03:46:20 UTC
3580397 Noah Misch 08 January 2015, 03:34:57 UTC Always set the six locale category environment variables in main(). Typical server invocations already achieved that. Invalid locale settings in the initial postmaster environment interfered, as could malloc() failure. Setting "LC_MESSAGES=pt_BR.utf8 LC_ALL=invalid" in the postmaster environment will now choose C-locale messages, not Brazilian Portuguese messages. Most localized programs, including all PostgreSQL frontend executables, do likewise. Users are unlikely to observe changes involving locale categories other than LC_MESSAGES. CheckMyDatabase() ensures that we successfully set LC_COLLATE and LC_CTYPE; main() sets the remaining three categories to locale "C", which almost cannot fail. Back-patch to 9.0 (all supported versions). 08 January 2015, 03:35:19 UTC
aae12e4 Noah Misch 08 January 2015, 03:33:58 UTC Reject ANALYZE commands during VACUUM FULL or another ANALYZE. vacuum()'s static variable handling makes it non-reentrant; an ensuing null pointer deference crashed the backend. Back-patch to 9.0 (all supported versions). 08 January 2015, 03:34:39 UTC
cbb2d9d Andres Freund 06 January 2015, 23:10:18 UTC Improve relcache invalidation handling of currently invisible relations. The corner case where a relcache invalidation tried to rebuild the entry for a referenced relation but couldn't find it in the catalog wasn't correct. The code tried to RelationCacheDelete/RelationDestroyRelation the entry. That didn't work when assertions are enabled because the latter contains an assertion ensuring the refcount is zero. It's also more generally a bad idea, because by virtue of being referenced somebody might actually look at the entry, which is possible if the error is trapped and handled via a subtransaction abort. Instead just error out, without deleting the entry. As the entry is marked invalid, the worst that can happen is that the invalid (and at some point unused) entry lingers in the relcache. Discussion: 22459.1418656530@sss.pgh.pa.us There should be no way to hit this case < 9.4 where logical decoding introduced a bug that can hit this. But since the code for handling the corner case is there it should do something halfway sane, so backpatch all the the way back. The logical decoding bug will be handled in a separate commit. 06 January 2015, 23:26:41 UTC
9dcfb2b Alvaro Herrera 06 January 2015, 18:16:29 UTC Fix thinko in plpython error message 06 January 2015, 18:16:29 UTC
1d74e16 Bruce Momjian 06 January 2015, 16:43:46 UTC Update copyright for 2015 Backpatch certain files through 9.0 06 January 2015, 16:43:46 UTC
17797e1 Andres Freund 04 January 2015, 14:35:48 UTC Add missing va_end() call to a early exit in dmetaphone.c's StringAt(). Pointed out by Coverity. Backpatch to all supported branches, the code has been that way for a long while. 04 January 2015, 14:35:48 UTC
07bec31 Magnus Hagander 03 January 2015, 12:18:54 UTC Make path to pg_service.conf absolute in documentation The system file is always in the absolute path /etc/, not relative. David Fetter 03 January 2015, 12:21:06 UTC
5f8fe02 Tom Lane 31 December 2014, 21:42:58 UTC Docs: improve descriptions of ISO week-numbering date features. Use the phraseology "ISO 8601 week-numbering year" in place of just "ISO year", and make related adjustments to other terminology. The point of this change is that it seems some people see "ISO year" and think "standard year", whereupon they're surprised when constructs like to_char(..., "IYYY-MM-DD") produce nonsensical results. Perhaps hanging a few more adjectives on it will discourage them from jumping to false conclusions. I put in an explicit warning against that specific usage, too, though the main point is to discourage people who haven't read this far down the page. In passing fix some nearby markup and terminology inconsistencies. 31 December 2014, 21:42:58 UTC
2600e44 Tom Lane 31 December 2014, 17:17:12 UTC Improve consistency of parsing of psql's magic variables. For simple boolean variables such as ON_ERROR_STOP, psql has for a long time recognized variant spellings of "on" and "off" (such as "1"/"0"), and it also made a point of warning you if you'd misspelled the setting. But these conveniences did not exist for other keyword-valued variables. In particular, though ECHO_HIDDEN and ON_ERROR_ROLLBACK include "on" and "off" as possible values, none of the alternative spellings for those were recognized; and to make matters worse the code would just silently assume "on" was meant for any unrecognized spelling. Several people have reported getting bitten by this, so let's fix it. In detail, this patch: * Allows all spellings recognized by ParseVariableBool() for ECHO_HIDDEN and ON_ERROR_ROLLBACK. * Reports a warning for unrecognized values for COMP_KEYWORD_CASE, ECHO, ECHO_HIDDEN, HISTCONTROL, ON_ERROR_ROLLBACK, and VERBOSITY. * Recognizes all values for all these variables case-insensitively; previously there was a mishmash of case-sensitive and case-insensitive behaviors. Back-patch to all supported branches. There is a small risk of breaking existing scripts that were accidentally failing to malfunction; but the consensus is that the chance of detecting real problems and preventing future mistakes outweighs this. 31 December 2014, 17:17:12 UTC
9b74f35 Tatsuo Ishii 30 December 2014, 10:37:55 UTC Fix resource leak pointed out by Coverity. 30 December 2014, 10:37:55 UTC
312efcf Bruce Momjian 30 December 2014, 02:25:23 UTC Backpatch variable renaming in formatting.c Backpatch a9c22d1480aa8e6d97a000292d05ef2b31bbde4e to make future backpatching easier. Backpatch through 9.0 30 December 2014, 02:25:23 UTC
a3e3dde Tom Lane 29 December 2014, 19:21:10 UTC Assorted minor fixes for psql metacommand docs. Document the long forms of \H \i \ir \o \p \r \w ... apparently, we have a long and dishonorable history of leaving out the unabbreviated names of psql backslash commands. Avoid saying "Unix shell"; we can just say "shell" with equal clarity, and not leave Windows users wondering whether the feature works for them. Improve consistency of documentation of \g \o \w metacommands. There's no reason to use slightly different wording or markup for each one. 29 December 2014, 19:21:10 UTC
a99ec2b Noah Misch 25 December 2014, 18:52:03 UTC Have config_sspi_auth() permit IPv6 localhost connections. Windows versions later than Windows Server 2003 map "localhost" to ::1. Account for that in the generated pg_hba.conf, fixing another oversight in commit f6dc6dd5ba54d52c0733aaafc50da2fbaeabb8b0. Back-patch to 9.0, like that commit. David Rowley and Noah Misch 25 December 2014, 19:10:21 UTC
8b70023 Tom Lane 24 December 2014, 21:35:23 UTC Add CST (China Standard Time) to our lists of timezone abbreviations. For some reason this seems to have been missed when the lists in src/timezone/tznames/ were first constructed. We can't put it in Default because of the conflict with US CST, but we should certainly list it among the alternative entries in Asia.txt. (I checked for other oversights, but all the other abbreviations that are in current use according to the IANA files seem to be accounted for.) Noted while responding to bug #12326. 24 December 2014, 21:35:54 UTC
b27679a Tom Lane 21 December 2014, 20:30:39 UTC Docs: clarify treatment of variadic functions with zero variadic arguments. Explain that you have to use "VARIADIC ARRAY[]" to pass an empty array to a variadic parameter position. This was already implicit in the text but it seems better to spell it out. Per a suggestion from David Johnston, though I didn't use his proposed wording. Back-patch to all supported branches. 21 December 2014, 20:31:29 UTC
fce3a71 Andres Freund 19 December 2014, 13:29:52 UTC Prevent potentially hazardous compiler/cpu reordering during lwlock release. In LWLockRelease() (and in 9.4+ LWLockUpdateVar()) we release enqueued waiters using PGSemaphoreUnlock(). As there are other sources of such unlocks backends only wake up if MyProc->lwWaiting is set to false; which is only done in the aforementioned functions. Before this commit there were dangers because the store to lwWaitLink could become visible before the store to lwWaitLink. This could both happen due to compiler reordering (on most compilers) and on some platforms due to the CPU reordering stores. The possible consequence of this is that a backend stops waiting before lwWaitLink is set to NULL. If that backend then tries to acquire another lock and has to wait there the list could become corrupted once the lwWaitLink store is finally performed. Add a write memory barrier to prevent that issue. Unfortunately the barrier support has been only added in 9.2. Given that the issue has not knowingly been observed in praxis it seems sufficient to prohibit compiler reordering using volatile for 9.0 and 9.1. Actual problems due to compiler reordering are more likely anyway. Discussion: 20140210134625.GA15246@awork2.anarazel.de 19 December 2014, 13:57:52 UTC
0c54cb0 Tom Lane 18 December 2014, 21:39:08 UTC Improve documentation about CASE and constant subexpressions. The possibility that constant subexpressions of a CASE might be evaluated at planning time was touched on in 9.17.1 (CASE expressions), but it really ought to be explained in 4.2.14 (Expression Evaluation Rules) which is the primary discussion of such topics. Add text and an example there, and revise the <note> under CASE to link there. Back-patch to all supported branches, since it's acted like this for a long time (though 9.2+ is probably worse because of its more aggressive use of constant-folding via replanning of nominally-prepared statements). Pre-9.4, also back-patch text added in commit 0ce627d4 about CASE versus aggregate functions. Tom Lane and David Johnston, per discussion of bug #12273. 18 December 2014, 21:39:08 UTC
d168d0e Noah Misch 18 December 2014, 08:55:17 UTC Recognize Makefile line continuations in fetchRegressOpts(). Back-patch to 9.0 (all supported versions). This is mere future-proofing in the context of the master branch, but commit f6dc6dd5ba54d52c0733aaafc50da2fbaeabb8b0 requires it of older branches. 18 December 2014, 08:58:03 UTC
6d45ee5 Noah Misch 18 December 2014, 03:48:40 UTC Lock down regression testing temporary clusters on Windows. Use SSPI authentication to allow connections exclusively from the OS user that launched the test suite. This closes on Windows the vulnerability that commit be76a6d39e2832d4b88c0e1cc381aa44a7f86881 closed on other platforms. Users of "make installcheck" or custom test harnesses can run "pg_regress --config-auth=DATADIR" to activate the same authentication configuration that "make check" would use. Back-patch to 9.0 (all supported versions). Security: CVE-2014-0067 18 December 2014, 03:48:48 UTC
a2969bd Tom Lane 16 December 2014, 20:35:49 UTC Fix off-by-one loop count in MapArrayTypeName, and get rid of static array. MapArrayTypeName would copy up to NAMEDATALEN-1 bytes of the base type name, which of course is wrong: after prepending '_' there is only room for NAMEDATALEN-2 bytes. Aside from being the wrong result, this case would lead to overrunning the statically allocated work buffer. This would be a security bug if the function were ever used outside bootstrap mode, but it isn't, at least not in any currently supported branches. Aside from fixing the off-by-one loop logic, this patch gets rid of the static work buffer by having MapArrayTypeName pstrdup its result; the sole caller was already doing that, so this just requires moving the pstrdup call. This saves a few bytes but mainly it makes the API a lot cleaner. Back-patch on the off chance that there is some third-party code using MapArrayTypeName with less-secure input. Pushing pstrdup into the function should not cause any serious problems for such hypothetical code; at worst there might be a short term memory leak. Per Coverity scanning. 16 December 2014, 20:35:49 UTC
961df18 Tom Lane 16 December 2014, 18:31:42 UTC Fix file descriptor leak after failure of a \setshell command in pgbench. If the called command fails to return data, runShellCommand forgot to pclose() the pipe before returning. This is fairly harmless in the current code, because pgbench would then abandon further processing of that client thread; so no more than nclients descriptors could be leaked this way. But it's not hard to imagine future improvements whereby that wouldn't be true. In any case, it's sloppy coding, so patch all branches. Found by Coverity. 16 December 2014, 18:32:38 UTC
662eebd Tom Lane 12 December 2014, 02:02:41 UTC Fix planning of SELECT FOR UPDATE on child table with partial index. Ordinarily we can omit checking of a WHERE condition that matches a partial index's condition, when we are using an indexscan on that partial index. However, in SELECT FOR UPDATE we must include the "redundant" filter condition in the plan so that it gets checked properly in an EvalPlanQual recheck. The planner got this mostly right, but improperly omitted the filter condition if the index in question was on an inheritance child table. In READ COMMITTED mode, this could result in incorrectly returning just-updated rows that no longer satisfy the filter condition. The cause of the error is using get_parse_rowmark() when get_plan_rowmark() is what should be used during planning. In 9.3 and up, also fix the same mistake in contrib/postgres_fdw. It's currently harmless there (for lack of inheritance support) but wrong is wrong, and the incorrect code might get copied to someplace where it's more significant. Report and fix by Kyotaro Horiguchi. Back-patch to all supported branches. 12 December 2014, 02:02:41 UTC
f5e4e92 Tom Lane 12 December 2014, 00:37:17 UTC Fix corner case where SELECT FOR UPDATE could return a row twice. In READ COMMITTED mode, if a SELECT FOR UPDATE discovers it has to redo WHERE-clause checking on rows that have been updated since the SELECT's snapshot, it invokes EvalPlanQual processing to do that. If this first occurs within a non-first child table of an inheritance tree, the previous coding could accidentally re-return a matching row from an earlier, already-scanned child table. (And, to add insult to injury, I think this could make it miss returning a row that should have been returned, if the updated row that this happens on should still have passed the WHERE qual.) Per report from Kyotaro Horiguchi; the added isolation test is based on his test case. This has been broken for quite awhile, so back-patch to all supported branches. 12 December 2014, 00:37:17 UTC
d67be55 Heikki Linnakangas 05 December 2014, 12:27:56 UTC Give a proper error message if initdb password file is empty. Used to say just "could not read password from file "...": Success", which isn't very informative. Mats Erik Andersson. Backpatch to all supported versions. 05 December 2014, 12:30:55 UTC
e655062 Tom Lane 01 December 2014, 20:25:18 UTC Guard against bad "dscale" values in numeric_recv(). We were not checking to see if the supplied dscale was valid for the given digit array when receiving binary-format numeric values. While dscale can validly be more than the number of nonzero fractional digits, it shouldn't be less; that case causes fractional digits to be hidden on display even though they're there and participate in arithmetic. Bug #12053 from Tommaso Sala indicates that there's at least one broken client library out there that sometimes supplies an incorrect dscale value, leading to strange behavior. This suggests that simply throwing an error might not be the best response; it would lead to failures in applications that might seem to be working fine today. What seems the least risky fix is to truncate away any digits that would be hidden by dscale. This preserves the existing behavior in terms of what will be printed for the transmitted value, while preventing subsequent arithmetic from producing results inconsistent with that. In passing, throw a specific error for the case of dscale being outside the range that will fit into a numeric's header. Before you got "value overflows numeric format", which is a bit misleading. Back-patch to all supported branches. 01 December 2014, 20:25:18 UTC
85a6ad3 Tom Lane 30 November 2014, 17:21:01 UTC Fix minor bugs in commit 30bf4689a96cd283af33edcdd6b7210df3f20cd8 et al. Coverity complained that the "else" added to fillPGconn() was unreachable, which it was. Remove the dead code. In passing, rearrange the tests so as not to bother trying to fetch values for options that can't be assigned. Pre-9.3 did not have that issue, but it did have a "return" that should be "goto oom_error" to ensure that a suitable error message gets filled in. 30 November 2014, 17:21:01 UTC
6a694bb Tom Lane 27 November 2014, 16:13:03 UTC Free libxml2/libxslt resources in a safer order. Mark Simonetti reported that libxslt sometimes crashes for him, and that swapping xslt_process's object-freeing calls around to do them in reverse order of creation seemed to fix it. I've not reproduced the crash, but valgrind clearly shows a reference to already-freed memory, which is consistent with the idea that shutdown of the xsltTransformContext is trying to reference the already-freed stylesheet or input document. With this patch, valgrind is no longer unhappy. I have an inquiry in to see if this is a libxslt bug or if we're just abusing the library; but even if it's a library bug, we'd want to adjust our code so it doesn't fail with unpatched libraries. Back-patch to all supported branches, because we've been doing this in the wrong(?) order for a long time. 27 November 2014, 16:13:03 UTC
9880fea Heikki Linnakangas 25 November 2014, 15:12:07 UTC Allow "dbname" from connection string to be overridden in PQconnectDBParams If the "dbname" attribute in PQconnectDBParams contained a connection string or URI (and expand_dbname = TRUE), the database name from the connection string could not be overridden by a subsequent "dbname" keyword in the array. That was not intentional; all other options can be overridden. Furthermore, any subsequent "dbname" caused the connection string from the first dbname value to be processed again, overriding any values for the same options that were given between the connection string and the second dbname option. In the passing, clarify in the docs that only the first dbname option in the array is parsed as a connection string. Alex Shulgin. Backpatch to all supported versions. 25 November 2014, 15:39:09 UTC
1f35170 Heikki Linnakangas 25 November 2014, 10:55:00 UTC Check return value of strdup() in libpq connection option parsing. An out-of-memory in most of these would lead to strange behavior, like connecting to a different database than intended, but some would lead to an outright segfault. Alex Shulgin and me. Backpatch to all supported versions. 25 November 2014, 12:10:54 UTC
d2e00c3 Tom Lane 19 November 2014, 21:00:40 UTC Improve documentation's description of JOIN clauses. In bug #12000, Andreas Kunert complained that the documentation was misleading in saying "FROM T1 CROSS JOIN T2 is equivalent to FROM T1, T2". That's correct as far as it goes, but the equivalence doesn't hold when you consider three or more tables, since JOIN binds more tightly than comma. I added a <note> to explain this, and ended up rearranging some of the existing text so that the note would make sense in context. In passing, rewrite the description of JOIN USING, which was unnecessarily vague, and hadn't been helped any by somebody's reliance on markup as a substitute for clear writing. (Mostly this involved reintroducing a concrete example that was unaccountably removed by commit 032f3b7e166cfa28.) Back-patch to all supported branches. 19 November 2014, 21:00:40 UTC
e1f9106 Tom Lane 19 November 2014, 02:36:59 UTC Don't require bleeding-edge timezone data in timestamptz regression test. The regression test cases added in commits b2cbced9e et al depended in part on the Russian timezone offset changes of Oct 2014. While this is of no particular concern for a default Postgres build, it was possible for a build using --with-system-tzdata to fail the tests if the system tzdata database wasn't au courant. Bjorn Munch and Christoph Berg both complained about this while packaging 9.4rc1, so we probably shouldn't insist on the system tzdata being up-to-date. Instead, make an equivalent test using a zone change that occurred in Venezuela in 2007. With this patch, the regression tests should pass using any tzdata set from 2012 or later. (I can't muster much sympathy for somebody using --with-system-tzdata on a machine whose system tzdata is more than three years out-of-date.) 19 November 2014, 02:36:59 UTC
9297957 Tom Lane 17 November 2014, 17:08:02 UTC Update time zone data files to tzdata release 2014j. DST law changes in the Turks & Caicos Islands (America/Grand_Turk) and in Fiji. New zone Pacific/Bougainville for portions of Papua New Guinea. Historical changes for Korea and Vietnam. 17 November 2014, 17:08:46 UTC
681dbe7 Heikki Linnakangas 13 November 2014, 17:47:44 UTC Fix race condition between hot standby and restoring a full-page image. There was a window in RestoreBackupBlock where a page would be zeroed out, but not yet locked. If a backend pinned and locked the page in that window, it saw the zeroed page instead of the old page or new page contents, which could lead to missing rows in a result set, or errors. To fix, replace RBM_ZERO with RBM_ZERO_AND_LOCK, which atomically pins, zeroes, and locks the page, if it's not in the buffer cache already. In stable branches, the old RBM_ZERO constant is renamed to RBM_DO_NOT_USE, to avoid breaking any 3rd party extensions that might use RBM_ZERO. More importantly, this avoids renumbering the other enum values, which would cause even bigger confusion in extensions that use ReadBufferExtended, but haven't been recompiled. Backpatch to all supported versions; this has been racy since hot standby was introduced. 13 November 2014, 18:00:51 UTC
ef5a3b9 Tom Lane 11 November 2014, 22:22:15 UTC Loop when necessary in contrib/pgcrypto's pktreader_pull(). This fixes a scenario in which pgp_sym_decrypt() failed with "Wrong key or corrupt data" on messages whose length is 6 less than a power of 2. Per bug #11905 from Connor Penhale. Fix by Marko Tiikkaja, regression test case from Jeff Janes. 11 November 2014, 22:22:58 UTC
39493e4 Tom Lane 07 November 2014, 01:52:40 UTC Cope with more than 64K phrases in a thesaurus dictionary. dict_thesaurus stored phrase IDs in uint16 fields, so it would get confused and even crash if there were more than 64K entries in the configuration file. It turns out to be basically free to widen the phrase IDs to uint32, so let's just do so. This was complained of some time ago by David Boutin (in bug #7793); he later submitted an informal patch but it was never acted on. We now have another complaint (bug #11901 from Luc Ouellette) so it's time to make something happen. This is basically Boutin's patch, but for future-proofing I also added a defense against too many words per phrase. Note that we don't need any explicit defense against overflow of the uint32 counters, since before that happens we'd hit array allocation sizes that repalloc rejects. Back-patch to all supported branches because of the crash risk. 07 November 2014, 01:53:07 UTC
83c7bfb Fujii Masao 06 November 2014, 12:25:45 UTC Prevent the unnecessary creation of .ready file for the timeline history file. Previously .ready file was created for the timeline history file at the end of an archive recovery even when WAL archiving was not enabled. This creation is unnecessary and causes .ready file to remain infinitely. This commit changes an archive recovery so that it creates .ready file for the timeline history file only when WAL archiving is enabled. Backpatch to all supported versions. 06 November 2014, 12:26:21 UTC
45a607d Tom Lane 04 November 2014, 18:24:26 UTC Drop no-longer-needed buffers during ALTER DATABASE SET TABLESPACE. The previous coding assumed that we could just let buffers for the database's old tablespace age out of the buffer arena naturally. The folly of that is exposed by bug #11867 from Marc Munro: the user could later move the database back to its original tablespace, after which any still-surviving buffers would match lookups again and appear to contain valid data. But they'd be missing any changes applied while the database was in the new tablespace. This has been broken since ALTER SET TABLESPACE was introduced, so back-patch to all supported branches. 04 November 2014, 18:24:26 UTC
12a9d64 Tom Lane 03 November 2014, 16:11:34 UTC Docs: fix incorrect spelling of contrib/pgcrypto option. pgp_sym_encrypt's option is spelled "sess-key", not "enable-session-key". Spotted by Jeff Janes. In passing, improve a comment in pgp-pgsql.c to make it clearer that the debugging options are intentionally undocumented. 03 November 2014, 16:11:59 UTC
73f950f Tom Lane 30 October 2014, 17:03:39 UTC Test IsInTransactionChain, not IsTransactionBlock, in vac_update_relstats. As noted by Noah Misch, my initial cut at fixing bug #11638 didn't cover all cases where ANALYZE might be invoked in an unsafe context. We need to test the result of IsInTransactionChain not IsTransactionBlock; which is notationally a pain because IsInTransactionChain requires an isTopLevel flag, which would have to be passed down through several levels of callers. I chose to pass in_outer_xact (ie, the result of IsInTransactionChain) rather than isTopLevel per se, as that seemed marginally more apropos for the intermediate functions to know about. 30 October 2014, 17:03:39 UTC
9d06da5 Tom Lane 29 October 2014, 22:12:20 UTC Avoid corrupting tables when ANALYZE inside a transaction is rolled back. VACUUM and ANALYZE update the target table's pg_class row in-place, that is nontransactionally. This is OK, more or less, for the statistical columns, which are mostly nontransactional anyhow. It's not so OK for the DDL hint flags (relhasindex etc), which might get changed in response to transactional changes that could still be rolled back. This isn't a problem for VACUUM, since it can't be run inside a transaction block nor in parallel with DDL on the table. However, we allow ANALYZE inside a transaction block, so if the transaction had earlier removed the last index, rule, or trigger from the table, and then we roll back the transaction after ANALYZE, the table would be left in a corrupted state with the hint flags not set though they should be. To fix, suppress the hint-flag updates if we are InTransactionBlock(). This is safe enough because it's always OK to postpone hint maintenance some more; the worst-case consequence is a few extra searches of pg_index et al. There was discussion of instead using a transactional update, but that would change the behavior in ways that are not all desirable: in most scenarios we're better off keeping ANALYZE's statistical values even if the ANALYZE itself rolls back. In any case we probably don't want to change this behavior in back branches. Per bug #11638 from Casey Shobe. This has been broken for a good long time, so back-patch to all supported branches. Tom Lane and Michael Paquier, initial diagnosis by Andres Freund 29 October 2014, 22:12:20 UTC
49ef4eb Heikki Linnakangas 29 October 2014, 12:32:01 UTC Reset error message at PQreset() If you call PQreset() repeatedly, and the connection cannot be re-established, the error messages from the failed connection attempts kept accumulating in the error string. Fixes bug #11455 reported by Caleb Epstein. Backpatch to all supported versions. 29 October 2014, 12:35:39 UTC
10059c2 Heikki Linnakangas 27 October 2014, 08:50:41 UTC Fix two bugs in tsquery @> operator. 1. The comparison for matching terms used only the CRC to decide if there's a match. Two different terms with the same CRC gave a match. 2. It assumed that if the second operand has more terms than the first, it's never a match. That assumption is bogus, because there can be duplicate terms in either operand. Rewrite the implementation in a way that doesn't have those bugs. Backpatch to all supported versions. 27 October 2014, 08:51:38 UTC
21fa26b Tom Lane 23 October 2014, 17:11:45 UTC Improve ispell dictionary's defenses against bad affix files. Don't crash if an ispell dictionary definition contains flags but not any compound affixes. (This isn't a security issue since only superusers can install affix files, but still it's a bad thing.) Also, be more careful about detecting whether an affix-file FLAG command is old-format (ispell) or new-format (myspell/hunspell). And change the error message about mixed old-format and new-format commands into something intelligible. Per bug #11770 from Emre Hasegeli. Back-patch to all supported branches. 23 October 2014, 17:11:45 UTC
ac6e875 Tom Lane 22 October 2014, 22:42:01 UTC Ensure libpq reports a suitable error message on unexpected socket EOF. The EOF-detection logic in pqReadData was a bit confused about who should set up the error message in case the kernel gives us read-ready-but-no-data rather than ECONNRESET or some other explicit error condition. Since the whole point of this situation is that the lower-level functions don't know there's anything wrong, pqReadData itself must set up the message. But keep the assumption that if an errno was reported, a message was set up at lower levels. Per bug #11712 from Marko Tiikkaja. It's been like this for a very long time, so back-patch to all supported branches. 22 October 2014, 22:42:01 UTC
98170fa Tom Lane 18 October 2014, 02:55:36 UTC Declare mkdtemp() only if we're providing it. Follow our usual style of providing an "extern" for a standard library function only when we're also providing the implementation. This avoids issues when the system headers declare the function slightly differently than we do, as noted by Caleb Welton. We might have to go to the extent of probing to see if the system headers declare the function, but let's not do that until it's demonstrated to be necessary. Oversight in commit 9e6b1bf258170e62dac555fc82ff0536dfe01d29. Back-patch to all supported branches, as that was. 18 October 2014, 02:55:36 UTC
31021e7 Tom Lane 17 October 2014, 16:49:15 UTC Fix core dump in pg_dump --binary-upgrade on zero-column composite type. This reverts nearly all of commit 28f6cab61ab8958b1a7dfb019724687d92722538 in favor of just using the typrelid we already have in pg_dump's TypeInfo struct for the composite type. As coded, it'd crash if the composite type had no attributes, since then the query would return no rows. Back-patch to all supported versions. It seems to not really be a problem in 9.0 because that version rejects the syntax "create type t as ()", but we might as well keep the logic similar in all affected branches. Report and fix by Rushabh Lathia. 17 October 2014, 16:49:15 UTC
870a980 Tom Lane 16 October 2014, 19:22:26 UTC Support timezone abbreviations that sometimes change. Up to now, PG has assumed that any given timezone abbreviation (such as "EDT") represents a constant GMT offset in the usage of any particular region; we had a way to configure what that offset was, but not for it to be changeable over time. But, as with most things horological, this view of the world is too simplistic: there are numerous regions that have at one time or another switched to a different GMT offset but kept using the same timezone abbreviation. Almost the entire Russian Federation did that a few years ago, and later this month they're going to do it again. And there are similar examples all over the world. To cope with this, invent the notion of a "dynamic timezone abbreviation", which is one that is referenced to a particular underlying timezone (as defined in the IANA timezone database) and means whatever it currently means in that zone. For zones that use or have used daylight-savings time, the standard and DST abbreviations continue to have the property that you can specify standard or DST time and get that time offset whether or not DST was theoretically in effect at the time. However, the abbreviations mean what they meant at the time in question (or most recently before that time) rather than being absolutely fixed. The standard abbreviation-list files have been changed to use this behavior for abbreviations that have actually varied in meaning since 1970. The old simple-numeric definitions are kept for abbreviations that have not changed, since they are a bit faster to resolve. While this is clearly a new feature, it seems necessary to back-patch it into all active branches, because otherwise use of Russian zone abbreviations is going to become even more problematic than it already was. This change supersedes the changes in commit 513d06ded et al to modify the fixed meanings of the Russian abbreviations; since we've not shipped that yet, this will avoid an undesirably incompatible (not to mention incorrect) change in behavior for timestamps between 2011 and 2014. This patch makes some cosmetic changes in ecpglib to keep its usage of datetime lookup tables as similar as possible to the backend code, but doesn't do anything about the increasingly obsolete set of timezone abbreviation definitions that are hard-wired into ecpglib. Whatever we do about that will likely not be appropriate material for back-patching. Also, a potential free() of a garbage pointer after an out-of-memory failure in ecpglib has been fixed. This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that caused it to produce unexpected results near a timezone transition, if both the "before" and "after" states are marked as standard time. We'd only ever thought about or tested transitions between standard and DST time, but that's not what's happening when a zone simply redefines their base GMT offset. In passing, update the SGML documentation to refer to the Olson/zoneinfo/ zic timezone database as the "IANA" database, since it's now being maintained under the auspices of IANA. 16 October 2014, 19:22:26 UTC
4487b85 Noah Misch 13 October 2014, 03:27:06 UTC Suppress dead, unportable src/port/crypt.c code. This file used __int64, which is specific to native Windows, rather than int64. Suppress the long-unused union field of this type. Noticed on Cygwin x86_64 with -lcrypt not installed. Back-patch to 9.0 (all supported versions). 13 October 2014, 03:27:36 UTC
0fbb172 Fujii Masao 09 October 2014, 18:18:01 UTC Fix broken example in PL/pgSQL document. Back-patch to all supported branches. Marti Raudsepp, per a report from Marko Tiikkaja 09 October 2014, 18:19:52 UTC
d9a1e9d Tom Lane 07 October 2014, 01:23:20 UTC Fix array overrun in ecpg's version of ParseDateTime(). The code wrote a value into the caller's field[] array before checking to see if there was room, which of course is backwards. Per report from Michael Paquier. I fixed the equivalent bug in the backend's version of this code way back in 630684d3a130bb93, but failed to think about ecpg's copy. Fortunately this doesn't look like it would be exploitable for anything worse than a core dump: an external attacker would have no control over the single word that gets written. 07 October 2014, 01:23:50 UTC
64a6285 Heikki Linnakangas 05 October 2014, 06:21:45 UTC Cannot rely on %z printf length modifier. Before version 9.4, we didn't require sprintf to support the %z length modifier. Use %lu instead. Reported by Peter Eisentraut. Apply to 9.3 and earlier. 05 October 2014, 06:57:07 UTC
b6391f5 Tom Lane 04 October 2014, 18:18:43 UTC Update time zone data files to tzdata release 2014h. Most zones in the Russian Federation are subtracting one or two hours as of 2014-10-26. Update the meanings of the abbreviations IRKT, KRAT, MAGT, MSK, NOVT, OMST, SAKT, VLAT, YAKT, YEKT to match. The IANA timezone database has adopted abbreviations of the form AxST/AxDT for all Australian time zones, reflecting what they believe to be current majority practice Down Under. These names do not conflict with usage elsewhere (other than ACST for Acre Summer Time, which has been in disuse since 1994). Accordingly, adopt these names into our "Default" timezone abbreviation set. The "Australia" abbreviation set now contains only CST,EAST,EST,SAST,SAT,WST, all of which are thought to be mostly historical usage. Note that SAST has also been changed to be South Africa Standard Time in the "Default" abbreviation set. Add zone abbreviations SRET (Asia/Srednekolymsk) and XJT (Asia/Urumqi), and use WSST/WSDT for western Samoa. Also a DST law change in the Turks & Caicos Islands (America/Grand_Turk), and numerous corrections for historical time zone data. 04 October 2014, 18:18:43 UTC
cc7bad3 Tom Lane 03 October 2014, 21:44:38 UTC Update time zone abbreviations lists. This updates known_abbrevs.txt to be what it should have been already, were my -P patch not broken; and updates some tznames/ entries that missed getting any love in previous timezone data updates because zic failed to flag the change of abbreviation. The non-cosmetic updates: * Remove references to "ADT" as "Arabia Daylight Time", an abbreviation that's been out of use since 2007; therefore, claiming there is a conflict with "Atlantic Daylight Time" doesn't seem especially helpful. (We have left obsolete entries in the files when they didn't conflict with anything, but that seems like a different situation.) * Fix entirely incorrect GMT offsets for CKT (Cook Islands), FJT, FJST (Fiji); we didn't even have them on the proper side of the date line. (Seems to have been aboriginal errors in our tznames data; there's no evidence anything actually changed recently.) * FKST (Falkland Islands Summer Time) is now used all year round, so don't mark it as a DST abbreviation. * Update SAKT (Sakhalin) to mean GMT+11 not GMT+10. In cosmetic changes, I fixed a bunch of wrong (or at least obsolete) claims about abbreviations not being present in the zic files, and tried to be consistent about how obsolete abbreviations are labeled. Note the underlying timezone/data files are still at release 2014e; this is just trying to get us in sync with what those files actually say before we go to the next update. 03 October 2014, 21:45:07 UTC
50a7576 Alvaro Herrera 03 October 2014, 16:01:27 UTC Don't balance vacuum cost delay when per-table settings are in effect When there are cost-delay-related storage options set for a table, trying to make that table participate in the autovacuum cost-limit balancing algorithm produces undesirable results: instead of using the configured values, the global values are always used, as illustrated by Mark Kirkwood in http://www.postgresql.org/message-id/52FACF15.8020507@catalyst.net.nz Since the mechanism is already complicated, just disable it for those cases rather than trying to make it cope. There are undesirable side-effects from this too, namely that the total I/O impact on the system will be higher whenever such tables are vacuumed. However, this is seen as less harmful than slowing down vacuum, because that would cause bloat to accumulate. Anyway, in the new system it is possible to tweak options to get the precise behavior one wants, whereas with the previous system one was simply hosed. This has been broken forever, so backpatch to all supported branches. This might affect systems where cost_limit and cost_delay have been set for individual tables. 03 October 2014, 16:01:27 UTC
f04b112 Heikki Linnakangas 03 October 2014, 09:07:10 UTC Check for GiST index tuples that don't fit on a page. The page splitting code would go into infinite recursion if you try to insert an index tuple that doesn't fit even on an empty page. Per analysis and suggested fix by Andrew Gierth. Fixes bug #11555, reported by Bryan Seitz (analysis happened over IRC). Backpatch to all supported versions. 03 October 2014, 11:50:58 UTC
98a68b4 Heikki Linnakangas 02 October 2014, 12:51:31 UTC Fix typo in error message. 02 October 2014, 12:52:48 UTC
288f15b Tom Lane 01 October 2014, 23:30:41 UTC Fix some more problems with nested append relations. As of commit a87c72915 (which later got backpatched as far as 9.1), we're explicitly supporting the notion that append relations can be nested; this can occur when UNION ALL constructs are nested, or when a UNION ALL contains a table with inheritance children. Bug #11457 from Nelson Page, as well as an earlier report from Elvis Pranskevichus, showed that there were still nasty bugs associated with such cases: in particular the EquivalenceClass mechanism could try to generate "join" clauses connecting an appendrel child to some grandparent appendrel, which would result in assertion failures or bogus plans. Upon investigation I concluded that all current callers of find_childrel_appendrelinfo() need to be fixed to explicitly consider multiple levels of parent appendrels. The most complex fix was in processing of "broken" EquivalenceClasses, which are ECs for which we have been unable to generate all the derived equality clauses we would like to because of missing cross-type equality operators in the underlying btree operator family. That code path is more or less entirely untested by the regression tests to date, because no standard opfamilies have such holes in them. So I wrote a new regression test script to try to exercise it a bit, which turned out to be quite a worthwhile activity as it exposed existing bugs in all supported branches. The present patch is essentially the same as far back as 9.2, which is where parameterized paths were introduced. In 9.0 and 9.1, we only need to back-patch a small fragment of commit 5b7b5518d, which fixes failure to propagate out the original WHERE clauses when a broken EC contains constant members. (The regression test case results show that these older branches are noticeably stupider than 9.2+ in terms of the quality of the plans generated; but we don't really care about plan quality in such cases, only that the plan not be outright wrong. A more invasive fix in the older branches would not be a good idea anyway from a plan-stability standpoint.) 01 October 2014, 23:30:41 UTC
bbe3c06 Robert Haas 26 September 2014, 15:21:35 UTC Fix identify_locking_dependencies for schema-only dumps. Without this fix, parallel restore of a schema-only dump can deadlock, because when the dump is schema-only, the dependency will still be pointing at the TABLE item rather than the TABLE DATA item. Robert Haas and Tom Lane 26 September 2014, 15:43:56 UTC
fc4314a Peter Eisentraut 14 September 2014, 14:50:04 UTC doc: Fix documentation of local_preload_libraries The documentation used to suggest setting this parameter with ALTER ROLE SET, but that never worked, so replace it with a working suggestion. Reported-by: Kyotaro Horiguchi <horiguchi.kyotaro@lab.ntt.co.jp> 14 September 2014, 14:57:06 UTC
1f89fc2 Stephen Frost 12 September 2014, 15:24:09 UTC Handle border = 3 in expanded mode In psql, expanded mode was not being displayed correctly when using the normal ascii or unicode linestyles and border set to '3'. Now, per the documentation, border '3' is really only sensible for HTML and LaTeX formats, however, that's no excuse for ascii/unicode to break in that case, and provisions had been made for psql to cleanly handle this case (and it did, in non-expanded mode). This was broken when ascii/unicode was initially added a good five years ago because print_aligned_vertical_line wasn't passed in the border setting being used by print_aligned_vertical but instead was given the whole printTableContent. There really isn't a good reason for vertical_line to have the entire printTableContent structure, so just pass in the printTextFormat and border setting (similar to how this is handled in horizontal_line). Pointed out by Pavel Stehule, fix by me. Back-patch to all currently-supported versions. 12 September 2014, 15:24:39 UTC
26f8a46 Tom Lane 12 September 2014, 03:31:06 UTC Fix power_var_int() for large integer exponents. The code for raising a NUMERIC value to an integer power wasn't very careful about large powers. It got an outright wrong answer for an exponent of INT_MIN, due to failure to consider overflow of the Abs(exp) operation; which is fixable by using an unsigned rather than signed exponent value after that point. Also, even though the number of iterations of the power-computation loop is pretty limited, it's easy for the repeated squarings to result in ridiculously enormous intermediate values, which can take unreasonable amounts of time/memory to process, or even overflow the internal "weight" field and so produce a wrong answer. We can forestall misbehaviors of that sort by bailing out as soon as the weight value exceeds what will fit in int16, since then the final answer must overflow (if exp > 0) or underflow (if exp < 0) the packed numeric format. Per off-list report from Pavel Stehule. Back-patch to all supported branches. 12 September 2014, 03:31:06 UTC
030fd8a Andres Freund 09 September 2014, 11:57:38 UTC Fix typo in solaris spinlock fix. 07968dbfaad03 missed part of the S_UNLOCK define when building for sparcv8+. 09 September 2014, 21:48:08 UTC
f25e896 Andres Freund 08 September 2014, 22:47:32 UTC Fix spinlock implementation for some !solaris sparc platforms. Some Sparc CPUs can be run in various coherence models, ranging from RMO (relaxed) over PSO (partial) to TSO (total). Solaris has always run CPUs in TSO mode while in userland, but linux didn't use to and the various *BSDs still don't. Unfortunately the sparc TAS/S_UNLOCK were only correct under TSO. Fix that by adding the necessary memory barrier instructions. On sparcv8+, which should be all relevant CPUs, these are treated as NOPs if the current consistency model doesn't require the barriers. Discussion: 20140630222854.GW26930@awork2.anarazel.de Will be backpatched to all released branches once a few buildfarm cycles haven't shown up problems. As I've no access to sparc, this is blindly written. 09 September 2014, 21:48:03 UTC
44c5183 Tom Lane 08 September 2014, 20:10:05 UTC Fix psql \s to work with recent libedit, and add pager support. psql's \s (print command history) doesn't work at all with recent libedit versions when printing to the terminal, because libedit tries to do an fchmod() on the target file which will fail if the target is /dev/tty. (We'd already noted this in the context of the target being /dev/null.) Even before that, it didn't work pleasantly, because libedit likes to encode the command history file (to ensure successful reloading), which renders it nigh unreadable, not to mention significantly different-looking depending on exactly which libedit version you have. So let's forget using write_history() for this purpose, and instead print the data ourselves, using logic similar to that used to iterate over the history for newline encoding/decoding purposes. While we're at it, insert the ability to use the pager when \s is printing to the terminal. This has been an acknowledged shortcoming of \s for many years, so while you could argue it's not exactly a back-patchable bug fix it still seems like a good improvement. Anyone who's seriously annoyed at this can use "\s /dev/tty" or local equivalent to get the old behavior. Experimentation with this showed that the history iteration logic was actually rather broken when used with libedit. It turns out that with libedit you have to use previous_history() not next_history() to advance to more recent history entries. The easiest and most robust fix for this seems to be to make a run-time test to verify which function to call. We had not noticed this because libedit doesn't really need the newline encoding logic: its own encoding ensures that command entries containing newlines are reloaded correctly (unlike libreadline). So the effective behavior with recent libedits was that only the oldest history entry got newline-encoded or newline-decoded. However, because of yet other bugs in history_set_pos(), some old versions of libedit allowed the existing loop logic to reach entries besides the oldest, which means there may be libedit ~/.psql_history files out there containing encoded newlines in more than just the oldest entry. To ensure we can reload such files, it seems appropriate to back-patch this fix, even though that will result in some incompatibility with older psql versions (ie, multiline history entries written by a psql with this fix will look corrupted to a psql without it, if its libedit is reasonably up to date). Stepan Rutz and Tom Lane 08 September 2014, 20:10:05 UTC
dd5b3f8 Tom Lane 08 September 2014, 02:40:41 UTC Documentation fix: sum(float4) returns float4, not float8. The old claim is from my commit d06ebdb8d3425185d7e641d15e45908658a0177d of 2000-07-17, but it seems to have been a plain old thinko; sum(float4) has been distinct from sum(float8) since Berkeley days. Noted by KaiGai Kohei. While at it, mention the existence of sum(money), which is also of embarrassingly ancient vintage. 08 September 2014, 02:41:10 UTC
857a5d6 Fujii Masao 04 September 2014, 17:17:57 UTC Fix segmentation fault that an empty prepared statement could cause. Back-patch to all supported branches. Per bug #11335 from Haruka Takatsuka 04 September 2014, 17:19:57 UTC
c1bbabe Kevin Grittner 30 August 2014, 16:05:57 UTC doc: Various typo/grammar fixes Errors detected using Topy (https://github.com/intgr/topy), all changes verified by hand and some manual tweaks added. Marti Raudsepp Individual changes backpatched, where applicable, as far as 9.0. 30 August 2014, 16:05:57 UTC
e6841c4 Noah Misch 19 August 2014, 03:00:38 UTC Install libpq DLL with $(INSTALL_SHLIB). Programs need execute permission on a DLL file to load it. MSYS "install" ignores the mode argument, and our Cygwin build statically links libpq into programs. That explains the lack of buildfarm trouble. Back-patch to 9.0 (all supported versions). 19 August 2014, 03:01:23 UTC
823be6b Tom Lane 18 August 2014, 05:17:49 UTC Fix obsolete mention of non-int64 support in CREATE SEQUENCE documentation. The old text explained what happened if we didn't have working int64 arithmetic. Since that case has been explicitly rejected by configure since 8.4.3, documenting it in the 9.x branches can only produce confusion. 18 August 2014, 05:18:24 UTC
c53127b Tom Lane 14 August 2014, 20:06:01 UTC Update SysV parameter configuration documentation for FreeBSD. FreeBSD hasn't made any use of kern.ipc.semmap since 1.1, and newer releases reject attempts to set it altogether; so stop recommending that it be adjusted. Per bug #11161. Back-patch to all supported branches. Before 9.3, also incorporate commit 7a42dff47, which touches the same text and for some reason was not back-patched at the time. 14 August 2014, 20:06:01 UTC
back to top