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
e1fa2d4 Tom Lane 17 March 2014, 19:39:12 UTC Stamp 8.4.21. 17 March 2014, 19:39:12 UTC
cc80df2 Tom Lane 17 March 2014, 19:28:38 UTC Release notes for 9.3.4, 9.2.8, 9.1.13, 9.0.17, 8.4.21. 17 March 2014, 19:28:38 UTC
cf64169 Peter Eisentraut 17 March 2014, 01:30:16 UTC Translation updates 17 March 2014, 01:57:28 UTC
962c148 Tom Lane 17 March 2014, 01:43:57 UTC Fix advertised dispsize for libpq's sslmode connection parameter. "8" was correct back when "disable" was the longest allowed value, but since "verify-full" was added, it should be "12". Given the lack of complaints, I wouldn't be surprised if nobody is actually using these values ... but still, if they're in the API, they should be right. Noticed while pursuing a different problem. It's been wrong for quite a long time, so back-patch to all supported branches. 17 March 2014, 01:43:57 UTC
6e6c2c2 Tom Lane 15 March 2014, 17:36:07 UTC Update time zone data files to tzdata release 2014a. DST law changes in Fiji, Turkey; historical changes in Israel, Ukraine. 15 March 2014, 17:36:57 UTC
810d6df Tom Lane 14 March 2014, 15:47:03 UTC Add missing #include. Commit 31400a673 and siblings added a check_stack_depth() call in contrib/intarray/_int_bool.c, but neglected to note that in our oldest branches that file didn't have the #include that defines that function. This results in a fortunately-harmless compiler warning. Per buildfarm. 14 March 2014, 15:47:03 UTC
172c53e Tom Lane 14 March 2014, 00:59:57 UTC Prevent interrupts while reporting non-ERROR elog messages. This should eliminate the risk of recursive entry to syslog(3), which appears to be the cause of the hang reported in bug #9551 from James Morton. Arguably, the real problem here is auth.c's willingness to turn on ImmediateInterruptOK while executing fairly wide swaths of backend code. We may well need to work at narrowing the code ranges in which the authentication_timeout interrupt is enabled. For the moment, though, this is a cheap and reasonably noninvasive fix for a field-reported failure; the other approach would be complex and not necessarily bug-free itself. Back-patch to all supported branches. 14 March 2014, 00:59:57 UTC
e2bccdf Heikki Linnakangas 12 March 2014, 07:59:49 UTC In WAL replay, restore GIN metapage unconditionally to avoid torn page. We don't take a full-page image of the GIN metapage; instead, the WAL record contains all the information required to reconstruct it from scratch. But to avoid torn page hazards, we must re-initialize it from the WAL record every time, even if it already has a greater LSN, similar to how normal full page images are restored. This was highly unlikely to cause any problems in practice, because the GIN metapage is small. We rely on an update smaller than a 512 byte disk sector to be atomic elsewhere, at least in pg_control. But better safe than sorry, and this would be easy to overlook if more fields are added to the metapage so that it's no longer small. Reported by Noah Misch. Backpatch to all supported versions. 12 March 2014, 08:10:04 UTC
d411d6e Heikki Linnakangas 07 March 2014, 11:25:11 UTC Fix dangling smgr_owner pointer when a fake relcache entry is freed. A fake relcache entry can "own" a SmgrRelation object, like a regular relcache entry. But when it was free'd, the owner field in SmgrRelation was not cleared, so it was left pointing to free'd memory. Amazingly this apparently hasn't caused crashes in practice, or we would've heard about it earlier. Andres found this with Valgrind. Report and fix by Andres Freund, with minor modifications by me. Backpatch to all supported versions. 07 March 2014, 11:43:28 UTC
ff9d757 Heikki Linnakangas 07 March 2014, 11:13:33 UTC Avoid memcpy() with same source and destination address. The behavior of that is undefined, although unlikely to lead to problems in practice. Found by running regression tests with Valgrind. 07 March 2014, 11:43:28 UTC
fb61ff8 Heikki Linnakangas 07 March 2014, 08:35:37 UTC Fix name of syslog_ident GUC in docs. Michael Paquier 07 March 2014, 08:38:25 UTC
f043bdd Tom Lane 07 March 2014, 00:31:22 UTC Avoid getting more than AccessShareLock when deparsing a query. In make_ruledef and get_query_def, we have long used AcquireRewriteLocks to ensure that the querytree we are about to deparse is up-to-date and the schemas of the underlying relations aren't changing. Howwever, that function thinks the query is about to be executed, so it acquires locks that are stronger than necessary for the purpose of deparsing. Thus for example, if pg_dump asks to deparse a rule that includes "INSERT INTO t", we'd acquire RowExclusiveLock on t. That results in interference with concurrent transactions that might for example ask for ShareLock on t. Since pg_dump is documented as being purely read-only, this is unexpected. (Worse, it used to actually be read-only; this behavior dates back only to 8.1, cf commit ba4200246.) Fix this by adding a parameter to AcquireRewriteLocks to tell it whether we want the "real" execution locks or only AccessShareLock. Report, diagnosis, and patch by Dean Rasheed. Back-patch to all supported branches. 07 March 2014, 00:31:22 UTC
b6e1434 Tom Lane 01 March 2014, 20:21:13 UTC Allow regex operations to be terminated early by query cancel requests. The regex code didn't have any provision for query cancel; which is unsurprising given its non-Postgres origin, but still problematic since some operations can take a long time. Introduce a callback function to check for a pending query cancel or session termination request, and call it in a couple of strategic spots where we can make the regex code exit with an error indicator. If we ever actually split out the regex code as a standalone library, some additional work will be needed to let the cancel callback function be specified externally to the library. But that's straightforward (certainly so by comparison to putting the locale-dependent character classification logic on a similar arms-length basis), and there seems no need to do it right now. A bigger issue is that there may be more places than these two where we need to check for cancels. We can always add more checks later, now that the infrastructure is in place. Since there are known examples of not-terribly-long regexes that can lock up a backend for a long time, back-patch to all supported branches. I have hopes of fixing the known performance problems later, but adding query cancel ability seems like a good idea even if they were all fixed. 01 March 2014, 20:21:13 UTC
dd378dd Tom Lane 18 February 2014, 17:44:36 UTC Remove broken code that tried to handle OVERLAPS with a single argument. The SQL standard says that OVERLAPS should have a two-element row constructor on each side. The original coding of OVERLAPS support in our grammar attempted to extend that by allowing a single-element row constructor, which it internally duplicated ... or tried to, anyway. But that code has certainly not worked since our List infrastructure was rewritten in 2004, and I'm none too sure it worked before that. As it stands, it ends up building a List that includes itself, leading to assorted undesirable behaviors later in the parser. Even if it worked as intended, it'd be a bit evil because of the possibility of duplicate evaluation of a volatile function that the user had written only once. Given the lack of documentation, test cases, or complaints, let's just get rid of the idea and only support the standard syntax. While we're at it, improve the error cursor positioning for the wrong-number-of-arguments errors, and inline the makeOverlaps() function since it's only called in one place anyway. Per bug #9227 from Joshua Yanovski. Initial patch by Joshua Yanovski, extended a bit by me. 18 February 2014, 17:44:36 UTC
a9c43b1 Peter Eisentraut 17 February 2014, 22:00:49 UTC Translation updates 17 February 2014, 22:00:49 UTC
0d90f08 Tom Lane 17 February 2014, 19:44:07 UTC Stamp 8.4.20. 17 February 2014, 19:44:07 UTC
56e55cf Tom Lane 17 February 2014, 19:25:54 UTC Last-minute updates for release notes. Add entries for security issues. Security: CVE-2014-0060 through CVE-2014-0067 17 February 2014, 19:25:54 UTC
f58663a Tom Lane 17 February 2014, 16:24:51 UTC Document risks of "make check" in the regression testing instructions. 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 17 February 2014, 16:24:51 UTC
69d2bc1 Tom Lane 17 February 2014, 16:20:38 UTC Prevent potential overruns of fixed-size buffers. 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() 17 February 2014, 16:20:38 UTC
98be8a6 Noah Misch 17 February 2014, 14:33:31 UTC Predict integer overflow to avoid buffer overruns. 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 17 February 2014, 14:33:39 UTC
d0ed1a6 Noah Misch 17 February 2014, 14:33:31 UTC Fix handling of wide datetime input/output. 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 17 February 2014, 14:33:39 UTC
e464761 Robert Haas 17 February 2014, 14:33:31 UTC Avoid repeated name lookups during table and index DDL. 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 17 February 2014, 14:33:38 UTC
09e2d4c Noah Misch 17 February 2014, 14:33:31 UTC Document security implications of check_function_bodies. Back-patch to 8.4 (all supported versions). 17 February 2014, 14:33:38 UTC
823b9dc Noah Misch 17 February 2014, 14:33:31 UTC Prevent privilege escalation in explicit calls to PL validators. 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 17 February 2014, 14:33:38 UTC
ff35425 Noah Misch 17 February 2014, 14:33:31 UTC Shore up ADMIN OPTION restrictions. 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 17 February 2014, 14:33:38 UTC
bde3307 Tom Lane 17 February 2014, 03:08:45 UTC Release notes for 9.3.3, 9.2.7, 9.1.12, 9.0.16, 8.4.20. 17 February 2014, 03:08:45 UTC
d77d93f Tom Lane 15 February 2014, 04:20:08 UTC Ooops, forgot to remove solar87 and friends from src/timezone/Makefile. Per buildfarm. 15 February 2014, 04:20:33 UTC
c0c2d62 Tom Lane 15 February 2014, 02:59:13 UTC Update time zone data files to tzdata release 2013i. 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. 15 February 2014, 02:59:56 UTC
b0154f2 Tom Lane 14 February 2014, 17:54:58 UTC Suggest shell here-documents instead of psql -c for multiple commands. 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. 14 February 2014, 17:54:58 UTC
7644a7b Tom Lane 13 February 2014, 23:45:32 UTC Clean up error cases in psql's COPY TO STDOUT/FROM STDIN code. 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. 13 February 2014, 23:45:32 UTC
a8a46d8 Tom Lane 13 February 2014, 19:24:58 UTC Fix length checking for Unicode identifiers containing escapes (U&"..."). 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. 13 February 2014, 19:24:58 UTC
42ec6a8 Tom Lane 13 February 2014, 00:09:32 UTC Improve cross-references between minor version release notes. 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 13 February 2014, 00:09:32 UTC
e99754a Tom Lane 12 February 2014, 23:16:50 UTC Improve text of stub HISTORY file. Per Peter Eisentraut. 12 February 2014, 23:16:50 UTC
c9256f5 Tom Lane 12 February 2014, 22:50:23 UTC Improve libpq's error recovery for connection loss during COPY. 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. 12 February 2014, 22:50:23 UTC
9620fed Tom Lane 12 February 2014, 19:52:32 UTC In XLogReadBufferExtended, don't assume P_NEW yields consecutive pages. 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. 12 February 2014, 19:52:32 UTC
432735c Tom Lane 11 February 2014, 01:48:30 UTC Don't generate plain-text HISTORY and src/test/regress/README anymore. 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. 11 February 2014, 01:48:30 UTC
6141983 Heikki Linnakangas 10 February 2014, 07:55:14 UTC Use memmove() instead of memcpy() for copying overlapping regions. In commit d2495f272cd164ff075bee5c4ce95aed11338a36, I fixed this bug in to_tsquery(), but missed the fact that plainto_tsquery() has the same bug. 10 February 2014, 08:00:50 UTC
55c0188 Andrew Dunstan 02 February 2014, 00:51:37 UTC Fix makefile syntax. 02 February 2014, 00:51:37 UTC
56f5d34 Tom Lane 01 February 2014, 23:27:12 UTC Fix some wide-character bugs in the text-search parser. 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. 01 February 2014, 23:27:12 UTC
ae3c98b Andrew Dunstan 01 February 2014, 20:16:52 UTC Copy the libpq DLL to the bin directory on Mingw and Cygwin. 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. 01 February 2014, 20:16:52 UTC
458b20f Robert Haas 01 February 2014, 02:31:08 UTC Clear MyProc and MyProcSignalState before they become invalid. 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. 01 February 2014, 02:41:09 UTC
01b882f Tom Lane 30 January 2014, 01:04:14 UTC Fix unsafe references to errno within error messaging logic. 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. 30 January 2014, 01:04:14 UTC
5525529 Fujii Masao 23 January 2014, 14:02:30 UTC Fix bugs in PQhost(). 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. 23 January 2014, 14:02:30 UTC
0fb4e3c Stephen Frost 18 January 2014, 23:41:52 UTC Allow SET TABLESPACE to database default 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. 18 January 2014, 23:50:47 UTC
15699d9 Peter Eisentraut 18 January 2014, 04:08:22 UTC Fix client-only installation 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 <mike.blackwell@rrd.com> 18 January 2014, 04:17:59 UTC
72cce2c Tom Lane 13 January 2014, 18:07:26 UTC Fix possible buffer overrun in contrib/pg_trgm. 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. 13 January 2014, 18:07:26 UTC
492b685 Heikki Linnakangas 13 January 2014, 13:42:35 UTC Fix calculation of ISMN check digit. This has always been broken, so back-patch to all supported versions. Fabien COELHO 13 January 2014, 13:44:14 UTC
d0070ac Tom Lane 11 January 2014, 21:35:44 UTC Fix possible crashes due to using elog/ereport too early in startup. 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. 11 January 2014, 21:35:44 UTC
00b7777 Tom Lane 11 January 2014, 18:41:41 UTC Fix compute_scalar_stats() for case that all values exceed WIDTH_THRESHOLD. 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. 11 January 2014, 18:42:11 UTC
d68a65b Michael Meskes 09 January 2014, 14:41:51 UTC Fix descriptor output in ECPG. 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 <maumau307@gmail.com> Conflicts: src/interfaces/ecpg/preproc/type.c src/interfaces/ecpg/test/expected/sql-desc.c 09 January 2014, 14:58:37 UTC
57ac7d8 Tom Lane 09 January 2014, 01:18:24 UTC Fix "cannot accept a set" error when only some arms of a CASE return a set. 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. 09 January 2014, 01:18:24 UTC
75c02a3 Bruce Momjian 07 January 2014, 21:05:29 UTC Update copyright for 2014 Update all files in head, and files COPYRIGHT and legal.sgml in all back branches. 07 January 2014, 21:05:29 UTC
96de493 Michael Meskes 01 January 2014, 11:24:19 UTC Do not use an empty hostname. When trying to connect to a given database libecpg should not try using an empty hostname if no hostname was given. 01 January 2014, 11:44:58 UTC
302cbc5 Kevin Grittner 29 December 2013, 21:19:46 UTC Don't attempt to limit target database for pg_restore. 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. 29 December 2013, 21:19:46 UTC
b2d8014 Kevin Grittner 27 December 2013, 21:41:46 UTC Fix misplaced right paren bugs in pgstatfuncs.c. 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. 27 December 2013, 21:41:46 UTC
69f77d7 Tatsuo Ishii 15 December 2013, 01:33:06 UTC Add "SHIFT_JIS" as an accepted encoding name for locale checking. 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. 15 December 2013, 02:11:11 UTC
45d0c1b Tom Lane 13 December 2013, 19:05:30 UTC Add HOLD/RESUME_INTERRUPTS in HandleCatchupInterrupt/HandleNotifyInterrupt. 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. 13 December 2013, 19:05:30 UTC
85eb066 Tom Lane 12 December 2013, 17:40:07 UTC Fix ancient docs/comments thinko: XID comparison is mod 2^32, not 2^31. Pointed out by Gianni Ciolli. 12 December 2013, 17:40:07 UTC
884c638 Tom Lane 10 December 2013, 21:10:36 UTC Fix possible crash with nested SubLinks. 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. 10 December 2013, 21:10:36 UTC
6c8b16e Joe Conway 08 December 2013, 00:56:34 UTC Fix performance regression in dblink connection speed. 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. 08 December 2013, 00:56:34 UTC
7635dae Tom Lane 05 December 2013, 17:48:44 UTC Clear retry flags properly in replacement OpenSSL sock_write function. 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. 05 December 2013, 17:48:44 UTC
67fc33d Heikki Linnakangas 03 December 2013, 20:13:16 UTC Fix full-page writes of internal GIN pages. 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. 03 December 2013, 20:53:26 UTC
be26515 Tom Lane 02 December 2013, 21:06:31 UTC Stamp 8.4.19. 02 December 2013, 21:06:31 UTC
67f898b Tom Lane 02 December 2013, 20:54:11 UTC Update release notes for 9.3.2, 9.2.6, 9.1.11, 9.0.15, 8.4.19. 02 December 2013, 20:54:11 UTC
28c1952 Peter Eisentraut 02 December 2013, 05:04:05 UTC Translation updates 02 December 2013, 05:04:05 UTC
0526889 Tom Lane 01 December 2013, 19:11:44 UTC Update time zone data files to tzdata release 2013h. DST law changes in Argentina, Brazil, Jordan, Libya, Liechtenstein, Morocco, Palestine. New timezone abbreviations WIB, WIT, WITA for Indonesia. 01 December 2013, 19:12:17 UTC
c361835 Tom Lane 01 December 2013, 19:09:31 UTC Back-patch src/timezone/known_abbrevs.txt into all active branches. Needed so that timezone data update patches can be cherry-picked into older branches conveniently. 01 December 2013, 19:09:59 UTC
ac7113b Kevin Grittner 30 November 2013, 18:07:18 UTC Fix pg_dumpall to work for databases flagged as read-only. pg_dumpall's charter is to be able to recreate a database cluster's contents in a virgin installation, but it was failing to honor that contract if the cluster had any ALTER DATABASE SET default_transaction_read_only settings. By including a SET command for the connection for each connection opened by pg_dumpall output, errors are avoided and the source cluster is successfully recreated. There was discussion of whether to also set this for the connection applying pg_dump output, but it was felt that it was both less appropriate in that context, and far easier to work around. Backpatch to all supported branches. 30 November 2013, 18:07:18 UTC
6cb109a Tom Lane 29 November 2013, 23:34:25 UTC Fix assorted issues in pg_ctl's pgwin32_CommandLine(). Ensure that the invocation command for postgres or pg_ctl runservice double-quotes the executable's pathname; failure to do this leads to trouble when the path contains spaces. Also, ensure that the path ends in ".exe" in both cases and uses backslashes rather than slashes as directory separators. The latter issue is reported to confuse some third-party tools such as Symantec Backup Exec. Also, rewrite the function to avoid buffer overrun issues by using a PQExpBuffer instead of a fixed-size static buffer. Combinations of very long executable pathnames and very long data directory pathnames could have caused trouble before, for example. Back-patch to all active branches, since this code has been like this for a long while. Naoya Anzai and Tom Lane, reviewed by Rajeev Rastogi 29 November 2013, 23:34:25 UTC
8a7f446 Heikki Linnakangas 27 November 2013, 11:10:16 UTC Don't update relfrozenxid if any pages were skipped. Vacuum recognizes that it can update relfrozenxid by checking whether it has processed all pages of a relation. Unfortunately it performed that check after truncating the dead pages at the end of the relation, and used the new number of pages to decide whether all pages have been scanned. If the new number of pages happened to be smaller or equal to the number of pages scanned, it incorrectly decided that all pages were scanned. This can lead to relfrozenxid being updated, even though some pages were skipped that still contain old XIDs. That can lead to data loss due to xid wraparounds with some rows suddenly missing. This likely has escaped notice so far because it takes a large number (~2^31) of xids being used to see the effect, while a full-table vacuum before that would fix the issue. The incorrect logic was introduced by commit b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8. Backpatch this fix down to 8.4, like that commit. Andres Freund, with some modifications by me. 27 November 2013, 11:40:05 UTC
3b41a7c Michael Meskes 26 November 2013, 16:12:39 UTC ECPG: Make the preprocessor emit ';' if the variable type for a list of variables is varchar. This fixes this test case: int main(void) { exec sql begin declare section; varchar a[50], b[50]; exec sql end declare section; return 0; } Since varchars are internally turned into custom structs and the type name is emitted for these variable declarations, the preprocessed code previously had: struct varchar_1 { ... } a _,_ struct varchar_2 { ... } b ; The comma in the generated C file was a syntax error. There are no regression test changes since it's not exercised. Patch by Boszormenyi Zoltan <zb@cybertec.at> Conflicts: src/interfaces/ecpg/preproc/ecpg.trailer 26 November 2013, 16:30:24 UTC
f142c27 Michael Meskes 26 November 2013, 16:16:39 UTC ECPG: Fix offset to NULL/size indicator array. Patch by Boszormenyi Zoltan <zb@cybertec.at> 26 November 2013, 16:25:42 UTC
2c3b7d2 Tom Lane 24 November 2013, 03:45:46 UTC Defend against bad trigger definitions in contrib/lo's lo_manage() trigger. This function formerly crashed if called as a statement-level trigger, or if a column-name argument wasn't given. In passing, add the trigger name to all error messages from the function. (None of them are expected cases, so this shouldn't pose any compatibility risk.) Marc Cousin, reviewed by Sawada Masahiko 24 November 2013, 03:46:21 UTC
d0378c8 Tom Lane 24 November 2013, 01:04:13 UTC Fix array slicing of int2vector and oidvector values. The previous coding labeled expressions such as pg_index.indkey[1:3] as being of int2vector type; which is not right because the subscript bounds of such a result don't, in general, satisfy the restrictions of int2vector. To fix, implicitly promote the result of slicing int2vector to int2[], or oidvector to oid[]. This is similar to what we've done with domains over arrays, which is a good analogy because these types are very much like restricted domains of the corresponding regular-array types. A side-effect is that we now also forbid array-element updates on such columns, eg while "update pg_index set indkey[4] = 42" would have worked before if you were superuser (and corrupted your catalogs irretrievably, no doubt) it's now disallowed. This seems like a good thing since, again, some choices of subscripting would've led to results not satisfying the restrictions of int2vector. The case of an array-slice update was rejected before, though with a different error message than you get now. We could make these cases work in future if we added a cast from int2[] to int2vector (with a cast function checking the subscript restrictions) but it seems unlikely that there's any value in that. Per report from Ronan Dunklau. Back-patch to all supported branches because of the crash risks involved. 24 November 2013, 01:04:13 UTC
3482f29 Tom Lane 23 November 2013, 23:24:26 UTC Ensure _dosmaperr() actually sets errno correctly. If logging is enabled, either ereport() or fprintf() might stomp on errno internally, causing this function to return the wrong result. That might only end in a misleading error report, but in any code that's examining errno to decide what to do next, the consequences could be far graver. This has been broken since the very first version of this file in 2006 ... it's a bit astonishing that we didn't identify this long ago. Reported by Amit Kapila, though this isn't his proposed fix. 23 November 2013, 23:25:00 UTC
240766a Peter Eisentraut 23 November 2013, 12:25:37 UTC Avoid potential buffer overflow crash A pointer to a C string was treated as a pointer to a "name" datum and passed to SPI_execute_plan(). This pointer would then end up being passed through datumCopy(), which would try to copy the entire 64 bytes of name data, thus running past the end of the C string. Fix by converting the string to a proper name structure. Found by LLVM AddressSanitizer. 23 November 2013, 12:31:53 UTC
122ba5d Tom Lane 22 November 2013, 19:37:38 UTC Flatten join alias Vars before pulling up targetlist items from a subquery. pullup_replace_vars()'s decisions about whether a pulled-up replacement expression needs to be wrapped in a PlaceHolderVar depend on the assumption that what looks like a Var behaves like a Var. However, if the Var is a join alias reference, later flattening of join aliases might replace the Var with something that's not a Var at all, and should have been wrapped. To fix, do a forcible pass of flatten_join_alias_vars() on the subquery targetlist before we start to copy items out of it. We'll re-run that processing on the pulled-up expressions later, but that's harmless. Per report from Ken Tanzer; the added regression test case is based on his example. This bug has been there since the PlaceHolderVar mechanism was invented, but has escaped detection because the circumstances that trigger it are fairly narrow. You need a flattenable query underneath an outer join, which contains another flattenable query inside a join of its own, with a dangerous expression (a constant or something else non-strict) in that one's targetlist. Having seen this, I'm wondering if it wouldn't be prudent to do all alias-variable flattening earlier, perhaps even in the rewriter. But that would probably not be a back-patchable change. 22 November 2013, 19:37:38 UTC
6765a2c Tom Lane 15 November 2013, 23:34:14 UTC Fix incorrect loop counts in tidbitmap.c. A couple of places that should have been iterating over WORDS_PER_CHUNK words were iterating over WORDS_PER_PAGE words instead. This thinko accidentally failed to fail, because (at least on common architectures with default BLCKSZ) WORDS_PER_CHUNK is a bit less than WORDS_PER_PAGE, and the extra words being looked at were always zero so nothing happened. Still, it's a bug waiting to happen if anybody ever fools with the parameters affecting TIDBitmap sizes, and it's a small waste of cycles too. So back-patch to all active branches. Etsuro Fujita 15 November 2013, 23:34:39 UTC
0d6a006 Tom Lane 13 November 2013, 18:29:45 UTC Clarify CREATE FUNCTION documentation about handling of typmods. The previous text was a bit misleading, as well as unnecessarily vague about what information would be discarded. Per gripe from Craig Skinner. 13 November 2013, 18:29:45 UTC
8633aa9 Magnus Hagander 12 November 2013, 11:53:32 UTC Fix doc links in README file to work with new website layout Per report from Colin 't Hart 12 November 2013, 11:54:54 UTC
b6f82ac Heikki Linnakangas 08 November 2013, 20:21:42 UTC Fix race condition in GIN posting tree page deletion. If a page is deleted, and reused for something else, just as a search is following a rightlink to it from its left sibling, the search would continue scanning whatever the new contents of the page are. That could lead to incorrect query results, or even something more curious if the page is reused for a different kind of a page. To fix, modify the search algorithm to lock the next page before releasing the previous one, and refrain from deleting pages from the leftmost branch of the tree. Add a new Concurrency section to the README, explaining why this works. There is a lot more one could say about concurrency in GIN, but that's for another patch. Backpatch to all supported versions. 08 November 2013, 20:23:19 UTC
90b07dd Tom Lane 08 November 2013, 16:37:17 UTC Make contain_volatile_functions/contain_mutable_functions look into SubLinks. This change prevents us from doing inappropriate subquery flattening in cases such as dangerous functions hidden inside a sub-SELECT in the targetlist of another sub-SELECT. That could result in unexpected behavior due to multiple evaluations of a volatile function, as in a recent complaint from Etienne Dube. It's been questionable from the very beginning whether these functions should look into subqueries (as noted in their comments), and this case seems to provide proof that they should. Because the new code only descends into SubLinks, not SubPlans or InitPlans, the change only affects the planner's behavior during prepjointree processing and not later on --- for example, you can still get it to use a volatile function in an indexqual if you wrap the function in (SELECT ...). That's a historical behavior, for sure, but it's reasonable given that the executor's evaluation rules for subplans don't depend on whether there are volatile functions inside them. In any case, we need to constrain the behavioral change as narrowly as we can to make this reasonable to back-patch. 08 November 2013, 16:37:17 UTC
3eb7776 Tom Lane 07 November 2013, 21:33:39 UTC Be more robust when strerror() doesn't give a useful result. Back-patch commits 8e68816cc2567642c6fcca4eaac66c25e0ae5ced and 8dace66e0735ca39b779922d02c24ea2686e6521 into the stable branches. Buildfarm testing revealed no great portability surprises, and it seems useful to have this robustness improvement in all branches. 07 November 2013, 21:33:39 UTC
72c8a58 Tom Lane 06 November 2013, 18:32:36 UTC Prevent creating window functions with default arguments. Insertion of default arguments doesn't work for window functions, which is likely to cause a crash at runtime if the implementation code doesn't check the number of actual arguments carefully. It doesn't seem worth working harder than this for pre-9.2 branches. 06 November 2013, 18:32:36 UTC
2268d1c Tom Lane 06 November 2013, 02:58:26 UTC Improve the error message given for modifying a window with frame clause. For rather inscrutable reasons, SQL:2008 disallows copying-and-modifying a window definition that has any explicit framing clause. The error message we gave for this only made sense if the referencing window definition itself contains an explicit framing clause, which it might well not. Moreover, in the context of an OVER clause it's not exactly obvious that "OVER (windowname)" implies copy-and-modify while "OVER windowname" does not. This has led to multiple complaints, eg bug #5199 from Iliya Krapchatov. Change to a hopefully more intelligible error message, and in the case where we have just "OVER (windowname)", add a HINT suggesting that omitting the parentheses will fix it. Also improve the related documentation. Back-patch to all supported branches. 06 November 2013, 02:58:26 UTC
5f8f8cb Michael Meskes 03 November 2013, 14:37:34 UTC Changed test case slightly so it doesn't have an unused typedef. 03 November 2013, 14:41:57 UTC
d74eaf3 Tom Lane 01 November 2013, 20:10:08 UTC Ensure all files created for a single BufFile have the same resource owner. Callers expect that they only have to set the right resource owner when creating a BufFile, not during subsequent operations on it. While we could insist this be fixed at the caller level, it seems more sensible for the BufFile to take care of it. Without this, some temp files belonging to a BufFile can go away too soon, eg at the end of a subtransaction, leading to errors or crashes. Reported and fixed by Andres Freund. Back-patch to all active branches. 01 November 2013, 20:10:08 UTC
01499ea Tom Lane 01 November 2013, 16:13:38 UTC Fix some odd behaviors when using a SQL-style simple GMT offset timezone. Formerly, when using a SQL-spec timezone setting with a fixed GMT offset (called a "brute force" timezone in the code), the session_timezone variable was not updated to match the nominal timezone; rather, all code was expected to ignore session_timezone if HasCTZSet was true. This is of course obviously fragile, though a search of the code finds only timeofday() failing to honor the rule. A bigger problem was that DetermineTimeZoneOffset() supposed that if its pg_tz parameter was pointer-equal to session_timezone, then HasCTZSet should override the parameter. This would cause datetime input containing an explicit zone name to be treated as referencing the brute-force zone instead, if the zone name happened to match the session timezone that had prevailed before installing the brute-force zone setting (as reported in bug #8572). The same malady could affect AT TIME ZONE operators. To fix, set up session_timezone so that it matches the brute-force zone specification, which we can do using the POSIX timezone definition syntax "<abbrev>offset", and get rid of the bogus lookaside check in DetermineTimeZoneOffset(). Aside from fixing the erroneous behavior in datetime parsing and AT TIME ZONE, this will cause the timeofday() function to print its result in the user-requested time zone rather than some previously-set zone. It might also affect results in third-party extensions, if there are any that make use of session_timezone without considering HasCTZSet, but in all cases the new behavior should be saner than before. Back-patch to all supported branches. 01 November 2013, 16:13:38 UTC
a1f86e7 Tom Lane 29 October 2013, 00:49:41 UTC Prevent using strncpy with src == dest in TupleDescInitEntry. The C and POSIX standards state that strncpy's behavior is undefined when source and destination areas overlap. While it remains dubious whether any implementations really misbehave when the pointers are exactly equal, some platforms are now starting to force the issue by complaining when an undefined call occurs. (In particular OS X 10.9 has been seen to dump core here, though the exact set of circumstances needed to trigger that remain elusive. Similar behavior can be expected to be optional on Linux and other platforms in the near future.) So tweak the code to explicitly do nothing when nothing need be done. Back-patch to all active branches. In HEAD, this also lets us get rid of an exception in valgrind.supp. Per discussion of a report from Matthias Schmitt. 29 October 2013, 00:49:41 UTC
de63db9 Peter Eisentraut 03 July 2013, 00:32:09 UTC doc: Remove i18ngurus.com link The web site is dead, and the Wayback Machine shows that it didn't have much useful content before. 21 October 2013, 10:32:20 UTC
8c64e93 Bruce Momjian 09 October 2013, 12:44:51 UTC doc: fix typo in release notes Backpatch through 8.4 Per suggestion by Amit Langote 09 October 2013, 12:44:51 UTC
e6a8de2 Peter Eisentraut 08 October 2013, 03:10:18 UTC Stamp 8.4.18. 08 October 2013, 03:10:18 UTC
3ac00d8 Bruce Momjian 08 October 2013, 01:35:01 UTC docs: update release notes for 8.4.18, 9.0.14, 9.1.10, 9.2.5, 9.3.1 08 October 2013, 01:35:01 UTC
45336e8 Peter Eisentraut 07 October 2013, 20:10:44 UTC Translation updates 07 October 2013, 20:10:44 UTC
50eeeb0 Peter Eisentraut 03 October 2013, 01:33:26 UTC doc: Correct psycopg URL 03 October 2013, 01:34:59 UTC
fef01d4 Heikki Linnakangas 30 September 2013, 08:29:09 UTC Fix snapshot leak if lo_open called on non-existent object. lo_open registers the currently active snapshot, and checks if the large object exists after that. Normally, snapshots registered by lo_open are unregistered at end of transaction when the lo descriptor is closed, but if we error out before the lo descriptor is added to the list of open descriptors, it is leaked. Fix by moving the snapshot registration to after checking if the large object exists. Reported by Pavel Stehule. Backpatch to 8.4. The snapshot registration system was introduced in 8.4, so prior versions are not affected (and not supported, anyway). 30 September 2013, 10:00:00 UTC
5fdab1e Heikki Linnakangas 26 September 2013, 08:24:40 UTC Fix spurious warning after vacuuming a page on a table with no indexes. There is a rare race condition, when a transaction that inserted a tuple aborts while vacuum is processing the page containing the inserted tuple. Vacuum prunes the page first, which normally removes any dead tuples, but if the inserting transaction aborts right after that, the loop after pruning will see a dead tuple and remove it instead. That's OK, but if the page is on a table with no indexes, and the page becomes completely empty after removing the dead tuple (or tuples) on it, it will be immediately marked as all-visible. That's OK, but the sanity check in vacuum would throw a warning because it thinks that the page contains dead tuples and was nevertheless marked as all-visible, even though it just vacuumed away the dead tuples and so it doesn't actually contain any. Spotted this while reading the code. It's difficult to hit the race condition otherwise, but can be done by putting a breakpoint after the heap_page_prune() call. Backpatch all the way to 8.4, where this code first appeared. 26 September 2013, 08:39:56 UTC
a6b831a Alvaro Herrera 24 September 2013, 21:19:14 UTC Fix pgindent comment breakage 24 September 2013, 21:22:10 UTC
d6dc44a Stephen Frost 23 September 2013, 12:48:47 UTC Fix SSL deadlock risk in libpq In libpq, we set up and pass to OpenSSL callback routines to handle locking. When we run out of SSL connections, we try to clean things up by de-registering the hooks. Unfortunately, we had a few calls into the OpenSSL library after these hooks were de-registered during SSL cleanup which lead to deadlocking. This moves the thread callback cleanup to be after all SSL-cleanup related OpenSSL library calls. I've been unable to reproduce the deadlock with this fix. In passing, also move the close_SSL call to be after unlocking our ssl_config mutex when in a failure state. While it looks pretty unlikely to be an issue, it could have resulted in deadlocks if we ended up in this code path due to something other than SSL_new failing. Thanks to Heikki for pointing this out. Back-patch to all supported versions; note that the close_SSL issue only goes back to 9.0, so that hunk isn't included in the 8.4 patch. Initially found and reported by Vesa-Matti J Kari; many thanks to both Heikki and Andres for their help running down the specific issue and reviewing the patch. 23 September 2013, 12:48:47 UTC
312116e Noah Misch 12 September 2013, 00:10:15 UTC Ignore interrupts during quickdie(). Once the administrator has called for an immediate shutdown or a backend crash has triggered a reinitialization, no mere SIGINT or SIGTERM should change that course. Such derailment remains possible when the signal arrives before quickdie() blocks signals. That being a narrow race affecting most PostgreSQL signal handlers in some way, leave it for another patch. Back-patch this to all supported versions. 12 September 2013, 00:17:52 UTC
back to top