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
f054f63 Tom Lane 23 February 2012, 22:56:26 UTC Stamp 9.0.7. 23 February 2012, 22:56:26 UTC
09189cb Tom Lane 23 February 2012, 22:48:05 UTC Last-minute release note updates. Security: CVE-2012-0866, CVE-2012-0867, CVE-2012-0868 23 February 2012, 22:48:05 UTC
02f013e Tom Lane 23 February 2012, 20:53:24 UTC Convert newlines to spaces in names written in pg_dump comments. pg_dump was incautious about sanitizing object names that are emitted within SQL comments in its output script. A name containing a newline would at least render the script syntactically incorrect. Maliciously crafted object names could present a SQL injection risk when the script is reloaded. Reported by Heikki Linnakangas, patch by Robert Haas Security: CVE-2012-0868 23 February 2012, 20:53:24 UTC
850d341 Tom Lane 23 February 2012, 20:48:14 UTC Remove arbitrary limitation on length of common name in SSL certificates. Both libpq and the backend would truncate a common name extracted from a certificate at 32 bytes. Replace that fixed-size buffer with dynamically allocated string so that there is no hard limit. While at it, remove the code for extracting peer_dn, which we weren't using for anything; and don't bother to store peer_cn longer than we need it in libpq. This limit was not so terribly unreasonable when the code was written, because we weren't using the result for anything critical, just logging it. But now that there are options for checking the common name against the server host name (in libpq) or using it as the user's name (in the server), this could result in undesirable failures. In the worst case it even seems possible to spoof a server name or user name, if the correct name is exactly 32 bytes and the attacker can persuade a trusted CA to issue a certificate in which that string is a prefix of the certificate's common name. (To exploit this for a server name, he'd also have to send the connection astray via phony DNS data or some such.) The case that this is a realistic security threat is a bit thin, but nonetheless we'll treat it as one. Back-patch to 8.4. Older releases contain the faulty code, but it's not a security problem because the common name wasn't used for anything interesting. Reported and patched by Heikki Linnakangas Security: CVE-2012-0867 23 February 2012, 20:48:14 UTC
de323d5 Tom Lane 23 February 2012, 20:39:07 UTC Require execute permission on the trigger function for CREATE TRIGGER. This check was overlooked when we added function execute permissions to the system years ago. For an ordinary trigger function it's not a big deal, since trigger functions execute with the permissions of the table owner, so they couldn't do anything the user issuing the CREATE TRIGGER couldn't have done anyway. However, if a trigger function is SECURITY DEFINER, that is not the case. The lack of checking would allow another user to install it on his own table and then invoke it with, essentially, forged input data; which the trigger function is unlikely to realize, so it might do something undesirable, for instance insert false entries in an audit log table. Reported by Dinesh Kumar, patch by Robert Haas Security: CVE-2012-0866 23 February 2012, 20:39:07 UTC
144fcf7 Peter Eisentraut 23 February 2012, 18:36:36 UTC Translation updates 23 February 2012, 18:36:36 UTC
31f2614 Peter Eisentraut 23 February 2012, 10:51:33 UTC Remove inappropriate quotes And adjust wording for consistency. 23 February 2012, 10:51:33 UTC
c2d11d2 Tom Lane 22 February 2012, 23:11:56 UTC Draft release notes for 9.1.3, 9.0.7, 8.4.11, 8.3.18. 22 February 2012, 23:12:39 UTC
140766d Alvaro Herrera 21 February 2012, 20:58:02 UTC REASSIGN OWNED: Support foreign data wrappers and servers This was overlooked when implementing those kinds of objects, in commit cae565e503c42a0942ca1771665243b4453c5770. Per report from Pawel Casperek. 22 February 2012, 20:32:23 UTC
315cb2f Simon Riggs 22 February 2012, 13:55:04 UTC Correctly initialise shared recoveryLastRecPtr in recovery. Previously we used ReadRecPtr rather than EndRecPtr, which was not a serious error but caused pg_stat_replication to report incorrect replay_location until at least one WAL record is replayed. Fujii Masao 22 February 2012, 13:55:04 UTC
e0eb632 Tom Lane 21 February 2012, 20:03:50 UTC Don't clear btpo_cycleid during _bt_vacuum_one_page. When "vacuuming" a single btree page by removing LP_DEAD tuples, we are not actually within a vacuum operation, but rather in an ordinary insertion process that could well be running concurrently with a vacuum. So clearing the cycleid is incorrect, and could cause the concurrent vacuum to miss removing tuples that it needs to remove. This is a longstanding bug introduced by commit e6284649b9e30372b3990107a082bc7520325676 of 2006-07-25. I believe it explains Maxim Boguk's recent report of index corruption, and probably some other previously unexplained reports. In 9.0 and up this is a one-line fix; before that we need to introduce a flag to tell _bt_delitems what to do. 21 February 2012, 20:03:50 UTC
d1ed336 Magnus Hagander 21 February 2012, 16:12:25 UTC Avoid double close of file handle in syslogger on win32 This causes an exception when running under a debugger or in particular when running on a debug version of Windows. Patch from MauMau 21 February 2012, 16:14:14 UTC
29f65a8 Tom Lane 20 February 2012, 21:21:41 UTC Don't reject threaded Python on FreeBSD. According to Chris Rees, this has worked for awhile, and the current FreeBSD port is removing the test anyway. 20 February 2012, 21:21:41 UTC
1fee1bf Tom Lane 20 February 2012, 05:52:49 UTC Fix regex back-references that are directly quantified with *. The syntax "\n*", that is a backref with a * quantifier directly applied to it, has never worked correctly in Spencer's library. This has been an open bug in the Tcl bug tracker since 2005: https://sourceforge.net/tracker/index.php?func=detail&aid=1115587&group_id=10894&atid=110894 The core of the problem is in parseqatom(), which first changes "\n*" to "\n+|" and then applies repeat() to the NFA representing the backref atom. repeat() thinks that any arc leading into its "rp" argument is part of the sub-NFA to be repeated. Unfortunately, since parseqatom() already created the arc that was intended to represent the empty bypass around "\n+", this arc gets moved too, so that it now leads into the state loop created by repeat(). Thus, what was supposed to be an "empty" bypass gets turned into something that represents zero or more repetitions of the NFA representing the backref atom. In the original example, in place of ^([bc])\1*$ we now have something that acts like ^([bc])(\1+|[bc]*)$ At runtime, the branch involving the actual backref fails, as it's supposed to, but then the other branch succeeds anyway. We could no doubt fix this by some rearrangement of the operations in parseqatom(), but that code is plenty ugly already, and what's more the whole business of converting "x*" to "x+|" probably needs to go away to fix another problem I'll mention in a moment. Instead, this patch suppresses the *-conversion when the target is a simple backref atom, leaving the case of m == 0 to be handled at runtime. This makes the patch in regcomp.c a one-liner, at the cost of having to tweak cbrdissect() a little. In the event I went a bit further than that and rewrote cbrdissect() to check all the string-length-related conditions before it starts comparing characters. It seems a bit stupid to possibly iterate through many copies of an n-character backreference, only to fail at the end because the target string's length isn't a multiple of n --- we could have found that out before starting. The existing coding could only be a win if integer division is hugely expensive compared to character comparison, but I don't know of any modern machine where that might be true. This does not fix all the problems with quantified back-references. In particular, the code is still broken for back-references that appear within a larger expression that is quantified (so that direct insertion of the quantification limits into the BACKREF node doesn't apply). I think fixing that will take some major surgery on the NFA code, specifically introducing an explicit iteration node type instead of trying to transform iteration into concatenation of modified regexps. Back-patch to all supported branches. In HEAD, also add a regression test case for this. (It may seem a bit silly to create a regression test file for just one test case; but I'm expecting that we will soon import a whole bunch of regex regression tests from Tcl, so might as well create the infrastructure now.) 20 February 2012, 05:52:49 UTC
f559846 Tom Lane 17 February 2012, 01:00:23 UTC Fix longstanding error in contrib/intarray's int[] & int[] operator. The array intersection code would give wrong results if the first entry of the correct output array would be "1". (I think only this value could be at risk, since the previous word would always be a lower-bound entry with that fixed value.) Problem spotted by Julien Rouhaud, initial patch by Guillaume Lelarge, cosmetic improvements by me. 17 February 2012, 01:00:23 UTC
ebc37d6 Michael Meskes 13 February 2012, 12:19:57 UTC Do not use the variable name when defining a varchar structure in ecpg. With a unique counter being added anyway, there is no need anymore to have the variable name listed, too. 13 February 2012, 14:49:38 UTC
0f3fcbb Andrew Dunstan 13 February 2012, 13:23:13 UTC Fix auto-explain JSON output to be valid JSON. Problem reported by Peter Eisentraut. Backpatched to release 9.0. 13 February 2012, 13:23:13 UTC
03c66ca Tom Lane 11 February 2012, 23:06:35 UTC Fix I/O-conversion-related memory leaks in plpgsql. Datatype I/O functions are allowed to leak memory in CurrentMemoryContext, since they are generally called in short-lived contexts. However, plpgsql calls such functions for purposes of type conversion, and was calling them in its procedure context. Therefore, any leaked memory would not be recovered until the end of the plpgsql function. If such a conversion was done within a loop, quite a bit of memory could get consumed. Fix by calling such functions in the transient "eval_econtext", and adjust other logic to match. Back-patch to all supported versions. Andres Freund, Jan Urbański, Tom Lane 11 February 2012, 23:06:35 UTC
5466072 Tom Lane 10 February 2012, 19:09:31 UTC Fix brain fade in previous pg_dump patch. In pre-7.3 databases, pg_attribute.attislocal doesn't exist. The easiest way to make sure the new inheritance logic behaves sanely is to assume it's TRUE, not FALSE. This will result in printing child columns even when they're not really needed. We could work harder at trying to reconstruct a value for attislocal, but there is little evidence that anyone still cares about dumping from such old versions, so just do the minimum necessary to have a valid dump. I had this correct in the original draft of the patch, but for some unaccountable reason decided it wasn't necessary to change the value. Testing against an old server shows otherwise... 10 February 2012, 19:09:31 UTC
ab060c7 Tom Lane 10 February 2012, 18:28:17 UTC Fix pg_dump for better handling of inherited columns. Revise pg_dump's handling of inherited columns, which was last looked at seriously in 2001, to eliminate several misbehaviors associated with inherited default expressions and NOT NULL flags. In particular make sure that a column is printed in a child table's CREATE TABLE command if and only if it has attislocal = true; the former behavior would sometimes cause a column to become marked attislocal when it was not so marked in the source database. Also, stop relying on textual comparison of default expressions to decide if they're inherited; instead, don't use default-expression inheritance at all, but just install the default explicitly at each level of the hierarchy. This fixes the search-path-related misbehavior recently exhibited by Chester Young, and also removes some dubious assumptions about the order in which ALTER TABLE SET DEFAULT commands would be executed. Back-patch to all supported branches. 10 February 2012, 18:28:17 UTC
cc0f6ff Tom Lane 06 February 2012, 20:29:26 UTC Fix postmaster to attempt restart after a hot-standby crash. The postmaster was coded to treat any unexpected exit of the startup process (i.e., the WAL replay process) as a catastrophic crash, and not try to restart it. This was OK so long as the startup process could not have any sibling postmaster children. However, if a hot-standby backend crashes, we SIGQUIT the startup process along with everything else, and the resulting exit is hardly "unexpected". Treating it as such meant we failed to restart a standby server after any child crash at all, not only a crash of the WAL replay process as intended. Adjust that. Back-patch to 9.0 where hot standby was introduced. 06 February 2012, 20:29:52 UTC
07e3641 Tom Lane 06 February 2012, 19:44:10 UTC Avoid throwing ERROR during WAL replay of DROP TABLESPACE. Although we will not even issue an XLOG_TBLSPC_DROP WAL record unless removal of the tablespace's directories succeeds, that does not guarantee that the same operation will succeed during WAL replay. Foreseeable reasons for it to fail include temp files created in the tablespace by Hot Standby backends, wrong directory permissions on a standby server, etc etc. The original coding threw ERROR if replay failed to remove the directories, but that is a serious overreaction. Throwing an error aborts recovery, and worse means that manual intervention will be needed to get the database to start again, since otherwise the same error will recur on subsequent attempts to replay the same WAL record. And the consequence of failing to remove the directories is only that some probably-small amount of disk space is wasted, so it hardly seems justified to throw an error. Accordingly, arrange to report such failures as LOG messages and keep going when a failure occurs during replay. Back-patch to 9.0 where Hot Standby was introduced. In principle such problems can occur in earlier releases, but Hot Standby increases the odds of trouble significantly. Given the lack of field reports of such issues, I'm satisfied with patching back as far as the patch applies easily. 06 February 2012, 19:44:10 UTC
852a5cd Tom Lane 06 February 2012, 18:14:52 UTC Avoid problems with OID wraparound during WAL replay. Fix a longstanding thinko in replay of NEXTOID and checkpoint records: we tried to advance nextOid only if it was behind the value in the WAL record, but the comparison would draw the wrong conclusion if OID wraparound had occurred since the previous value. Better to just unconditionally assign the new value, since OID assignment shouldn't be happening during replay anyway. The consequences of a failure to update nextOid would be pretty minimal, since we have long had the code set up to obtain another OID and try again if the generated value is already in use. But in the worst case there could be significant performance glitches while such loops iterate through many already-used OIDs before finding a free one. The odds of a wraparound happening during WAL replay would be small in a crash-recovery scenario, and the length of any ensuing OID-assignment stall quite limited anyway. But neither of these statements hold true for a replication slave that follows a WAL stream for a long period; its behavior upon going live could be almost unboundedly bad. Hence it seems worth back-patching this fix into all supported branches. Already fixed in HEAD in commit c6d76d7c82ebebb7210029f7382c0ebe2c558bca. 06 February 2012, 18:14:52 UTC
94c5aa6 Alvaro Herrera 06 February 2012, 14:53:22 UTC fe-misc.c depends on pg_config_paths.h Declare this in Makefile to avoid failures in parallel compiles. Author: Lionel Elie Mamane 06 February 2012, 14:53:22 UTC
2b196f0 Tom Lane 05 February 2012, 20:49:17 UTC Fix transient clobbering of shared buffers during WAL replay. RestoreBkpBlocks was in the habit of zeroing and refilling the target buffer; which was perfectly safe when the code was written, but is unsafe during Hot Standby operation. The reason is that we have coding rules that allow backends to continue accessing a tuple in a heap relation while holding only a pin on its buffer. Such a backend could see transiently zeroed data, if WAL replay had occasion to change other data on the page. This has been shown to be the cause of bug #6425 from Duncan Rance (who deserves kudos for developing a sufficiently-reproducible test case) as well as Bridget Frey's re-report of bug #6200. It most likely explains the original report as well, though we don't yet have confirmation of that. To fix, change the code so that only bytes that are supposed to change will change, even transiently. This actually saves cycles in RestoreBkpBlocks, since it's not writing the same bytes twice. Also fix seq_redo, which has the same disease, though it has to work a bit harder to meet the requirement. So far as I can tell, no other WAL replay routines have this type of bug. In particular, the index-related replay routines, which would certainly be broken if they had to meet the same standard, are not at risk because we do not have coding rules that allow access to an index page when not holding a buffer lock on it. Back-patch to 9.0 where Hot Standby was added. 05 February 2012, 20:49:46 UTC
a286b6f Simon Riggs 01 February 2012, 09:33:16 UTC Resolve timing issue with logging locks for Hot Standby. We log AccessExclusiveLocks for replay onto standby nodes, but because of timing issues on ProcArray it is possible to log a lock that is still held by a just committed transaction that is very soon to be removed. To avoid any timing issue we avoid applying locks made by transactions with InvalidXid. Simon Riggs, bug report Tom Lane, diagnosis Pavan Deolasee 01 February 2012, 09:33:16 UTC
8bff640 Heikki Linnakangas 30 January 2012, 08:32:46 UTC Accept a non-existent value in "ALTER USER/DATABASE SET ..." command. When default_text_search_config, default_tablespace, or temp_tablespaces setting is set per-user or per-database, with an "ALTER USER/DATABASE SET ..." statement, don't throw an error if the text search configuration or tablespace does not exist. In case of text search configuration, even if it doesn't exist in the current database, it might exist in another database, where the setting is intended to have its effect. This behavior is now the same as search_path's. Tablespaces are cluster-wide, so the same argument doesn't hold for tablespaces, but there's a problem with pg_dumpall: it dumps "ALTER USER SET ..." statements before the "CREATE TABLESPACE" statements. Arguably that's pg_dumpall's fault - it should dump the statements in such an order that the tablespace is created first and then the "ALTER USER SET default_tablespace ..." statements after that - but it seems better to be consistent with search_path and default_text_search_config anyway. Besides, you could still create a dump that throws an error, by creating the tablespace, running "ALTER USER SET default_tablespace", then dropping the tablespace and running pg_dumpall on that. Backpatch to all supported versions. 30 January 2012, 09:39:26 UTC
a752952 Tom Lane 28 January 2012, 04:09:16 UTC Fix error detection in contrib/pgcrypto's encrypt_iv() and decrypt_iv(). Due to oversights, the encrypt_iv() and decrypt_iv() functions failed to report certain types of invalid-input errors, and would instead return random garbage values. Marko Kreen, per report from Stefan Kaltenbrunner 28 January 2012, 04:09:44 UTC
2f66c1a Magnus Hagander 27 January 2012, 09:36:27 UTC Fix wording, per Peter Geoghegan 27 January 2012, 09:37:23 UTC
e5f97c5 Tom Lane 12 January 2012, 21:40:24 UTC Fix CLUSTER/VACUUM FULL for toast values owned by recently-updated rows. In commit 7b0d0e9356963d5c3e4d329a917f5fbb82a2ef05, I made CLUSTER and VACUUM FULL try to preserve toast value OIDs from the original toast table to the new one. However, if we have to copy both live and recently-dead versions of a row that has a toasted column, those versions may well reference the same toast value with the same OID. The patch then led to duplicate-key failures as we tried to insert the toast value twice with the same OID. (The previous behavior was not very desirable either, since it would have silently inserted the same value twice with different OIDs. That wastes space, but what's worse is that the toast values inserted for already-dead heap rows would not be reclaimed by subsequent ordinary VACUUMs, since they go into the new toast table marked live not deleted.) To fix, check if the copied OID already exists in the new toast table, and if so, assume that it stores the desired value. This is reasonably safe since the only case where we will copy an OID from a previous toast pointer is when toast_insert_or_update was given that toast pointer and so we just pulled the data from the old table; if we got two different values that way then we have big problems anyway. We do have to assume that no other backend is inserting items into the new toast table concurrently, but that's surely safe for CLUSTER and VACUUM FULL. Per bug #6393 from Maxim Boguk. Back-patch to 9.0, same as the previous patch. 12 January 2012, 21:40:24 UTC
e3fce28 Tom Lane 10 January 2012, 00:56:27 UTC Fix one-byte buffer overrun in contrib/test_parser. The original coding examined the next character before verifying that there *is* a next character. In the worst case with the input buffer right up against the end of memory, this would result in a segfault. Problem spotted by Paul Guyot; this commit extends his patch to fix an additional case. In addition, make the code a tad more readable by not overloading the usage of *tlen. 10 January 2012, 00:57:33 UTC
bb65cb8 Tom Lane 07 January 2012, 20:39:05 UTC Use __sync_lock_test_and_set() for spinlocks on ARM, if available. Historically we've used the SWPB instruction for TAS() on ARM, but this is deprecated and not available on ARMv6 and later. Instead, make use of a GCC builtin if available. We'll still fall back to SWPB if not, so as not to break existing ports using older GCC versions. Eventually we might want to try using __sync_lock_test_and_set() on some other architectures too, but for now that seems to present only risk and not reward. Back-patch to all supported versions, since people might want to use any of them on more recent ARM chips. Martin Pitt 07 January 2012, 20:39:05 UTC
1f996ad Tom Lane 06 January 2012, 18:04:24 UTC Fix pg_restore's direct-to-database mode for INSERT-style table data. In commit 6545a901aaf84cb05212bb6a7674059908f527c3, I removed the mini SQL lexer that was in pg_backup_db.c, thinking that it had no real purpose beyond separating COPY data from SQL commands, which purpose had been obsoleted by long-ago fixes in pg_dump's archive file format. Unfortunately this was in error: that code was also used to identify command boundaries in INSERT-style table data, which is run together as a single string in the archive file for better compressibility. As a result, direct-to-database restores from archive files made with --inserts or --column-inserts fail in our latest releases, as reported by Dick Visser. To fix, restore the mini SQL lexer, but simplify it by adjusting the calling logic so that it's only required to cope with INSERT-style table data, not arbitrary SQL commands. This allows us to not have to deal with SQL comments, E'' strings, or dollar-quoted strings, none of which have ever been emitted by dumpTableData_insert. Also, fix the lexer to cope with standard-conforming strings, which was the actual bug that the previous patch was meant to solve. Back-patch to all supported branches. The previous patch went back to 8.2, which unfortunately means that the EOL release of 8.2 contains this bug, but I don't think we're doing another 8.2 release just because of that. 06 January 2012, 18:04:24 UTC
c024a3b Tom Lane 04 January 2012, 23:31:08 UTC Make executor's SELECT INTO code save and restore original tuple receiver. As previously coded, the QueryDesc's dest pointer was left dangling (pointing at an already-freed receiver object) after ExecutorEnd. It's a bit astonishing that it took us this long to notice, and I'm not sure that the known problem case with SQL functions is the only one. Fix it by saving and restoring the original receiver pointer, which seems the most bulletproof way of ensuring any related bugs are also covered. Per bug #6379 from Paul Ramsey. Back-patch to 8.4 where the current handling of SELECT INTO was introduced. 04 January 2012, 23:31:08 UTC
7443ab2 Tom Lane 21 December 2011, 23:23:24 UTC Update per-column ACLs, not only per-table ACL, when changing table owner. We forgot to modify column ACLs, so privileges were still shown as having been granted by the old owner. This meant that neither the new owner nor a superuser could revoke the now-untraceable-to-table-owner permissions. Per bug #6350 from Marc Balmer. This has been wrong since column ACLs were added, so back-patch to 8.4. 21 December 2011, 23:23:24 UTC
61dd2ff Tom Lane 20 December 2011, 20:00:47 UTC Avoid crashing when we have problems unlinking files post-commit. smgrdounlink takes care to not throw an ERROR if it fails to unlink something, but that caution was rendered useless by commit 3396000684b41e7e9467d1abc67152b39e697035, which put an smgrexists call in front of it; smgrexists *does* throw error if anything looks funny, such as getting a permissions error from trying to open the file. If that happens post-commit, you get a PANIC, and what's worse the same logic appears in the WAL replay code, so the database even fails to restart. Restore the intended behavior by removing the smgrexists call --- it isn't accomplishing anything that we can't do better by adjusting mdunlink's ideas of whether it ought to warn about ENOENT or not. Per report from Joseph Shraibman of unrecoverable crash after trying to drop a table whose FSM fork had somehow gotten chmod'd to 000 permissions. Backpatch to 8.4, where the bogus coding was introduced. 20 December 2011, 20:00:47 UTC
458a83a Michael Meskes 18 December 2011, 14:34:33 UTC In ecpg removed old leftover check for given connection name. Ever since we introduced real prepared statements this should work for different connections. The old solution just emulating prepared statements, though, wasn't able to handle this. Closes: #6309 18 December 2011, 17:46:00 UTC
faa6955 Heikki Linnakangas 16 December 2011, 13:03:36 UTC Fix reference to "verify-ca" and "verify-full" in a note in the docs. 16 December 2011, 13:07:02 UTC
517462f Andrew Dunstan 14 December 2011, 22:13:01 UTC Disable excessive FP optimization by recent versions of gcc. Suggested solution from Tom Lane. Problem discovered, probably not for the first time, while testing the mingw-w64 32 bit compiler. Backpatched to all live branches. 14 December 2011, 22:13:01 UTC
6c0a375 Heikki Linnakangas 12 December 2011, 07:49:47 UTC Revert the behavior of inet/cidr functions to not unpack the arguments. I forgot to change the functions to use the PG_GETARG_INET_PP() macro, when I changed DatumGetInetP() to unpack the datum, like Datum*P macros usually do. Also, I screwed up the definition of the PG_GETARG_INET_PP() macro, and didn't notice because it wasn't used. This fixes the memory leak when sorting inet values, as reported by Jochen Erwied and debugged by Andres Freund. Backpatch to 8.3, like the previous patch that broke it. 12 December 2011, 08:05:24 UTC
94b18c6 Heikki Linnakangas 09 December 2011, 12:32:42 UTC Don't set reachedMinRecoveryPoint during crash recovery. In crash recovery, we don't reach consistency before replaying all of the WAL. Rename the variable to reachedConsistency, to make its intention clearer. In master, that was an active bug because of the recent patch to immediately PANIC if a reference to a missing page is found in WAL after reaching consistency, as Tom Lane's test case demonstrated. In 9.1 and 9.0, the only consequence was a misleading "consistent recovery state reached at %X/%X" message in the log at the beginning of crash recovery (the database is not consistent at that point yet). In 8.4, the log message was not printed in crash recovery, even though there was a similar reachedMinRecoveryPoint local variable that was also set early. So, backpatch to 9.1 and 9.0. 09 December 2011, 13:50:19 UTC
ec21805 Bruce Momjian 05 December 2011, 21:45:01 UTC In pg_upgrade, allow tables using regclass to be upgraded because we preserve pg_class oids since PG 9.0. 05 December 2011, 21:45:01 UTC
621fd4d Michael Meskes 03 December 2011, 20:03:57 UTC Applied another patch by Zoltan to fix memory alignement issues in ecpg's sqlda code. 04 December 2011, 03:43:33 UTC
f3bbd7d Magnus Hagander 03 December 2011, 14:02:53 UTC Treat ENOTDIR as ENOENT when looking for client certificate file This makes it possible to use a libpq app with home directory set to /dev/null, for example - treating it the same as if the file doesn't exist (which it doesn't). Per bug #6302, reported by Diego Elio Petteno 03 December 2011, 14:05:50 UTC
8af71fc Tom Lane 02 December 2011, 16:33:53 UTC Add some weasel wording about threaded usage of PGresults. PGresults used to be read-only from the application's viewpoint, but now that we've exposed various functions that allow modification of a PGresult, that sweeping statement is no longer accurate. Noted by Dmitriy Igrishin. 02 December 2011, 16:34:20 UTC
1c635b0 Tom Lane 01 December 2011, 21:49:59 UTC Stamp 9.0.6. 01 December 2011, 21:49:59 UTC
da1eacb Tom Lane 01 December 2011, 21:39:07 UTC Clarify documentation about SQL:2008 variant of LIMIT/OFFSET syntax. The point that you need parentheses for non-constant expressions apparently needs to be brought out a bit more clearly, per bug #6315. 01 December 2011, 21:39:07 UTC
698bb4e Peter Eisentraut 01 December 2011, 20:59:40 UTC Translation updates 01 December 2011, 20:59:40 UTC
efb7423 Tom Lane 01 December 2011, 17:44:28 UTC Fix getTypeIOParam to support type record[]. Since record[] uses array_in, it needs to have its element type passed as typioparam. In HEAD and 9.1, this fix essentially reverts commit 9bc933b2125a5358722490acbc50889887bf7680, which was a hack that is no longer needed since domains don't set their typelem anymore. Before that, adjust the logic so that only domains are excluded from being treated like arrays, rather than assuming that only base types should be included. Add a regression test to demonstrate the need for this. Per report from Maxim Boguk. Back-patch to 8.4, where type record[] was added. 01 December 2011, 17:44:28 UTC
83c461e Tom Lane 01 December 2011, 01:55:10 UTC Update information about configuring SysV IPC parameters on NetBSD. Per Emmanuel Kasper, sysctl works fine as of NetBSD 5.0. 01 December 2011, 01:55:10 UTC
33dcc3e Tom Lane 01 December 2011, 00:34:57 UTC Draft release notes for 9.1.2, 9.0.6, 8.4.10, 8.3.17, 8.2.23. 01 December 2011, 00:34:57 UTC
11fa083 Tom Lane 30 November 2011, 16:48:05 UTC Update time zone data files to tzdata release 2011n. DST law changes in Brazil, Cuba, Fiji, Palestine, Russia, Samoa. Historical corrections for Alaska and British East Africa. 30 November 2011, 16:48:36 UTC
b06c6f5 Tom Lane 30 November 2011, 05:37:20 UTC Tweak previous patch to ensure edata->filename always gets initialized. On a platform that isn't supplying __FILE__, previous coding would either crash or give a stale result for the filename string. Not sure how likely that is, but the original code catered for it, so let's keep doing so. 30 November 2011, 05:37:20 UTC
75b6183 Peter Eisentraut 29 November 2011, 20:04:59 UTC Strip file names reported in error messages in vpath builds In vpath builds, the __FILE__ macro that is used in verbose error reports contains the full absolute file name, which makes the error messages excessively verbose. So keep only the base name, thus matching the behavior of non-vpath builds. 29 November 2011, 21:51:28 UTC
d16ebde Tom Lane 28 November 2011, 18:52:09 UTC Remove erroneous claim about use of pg_locks.objid for advisory locks. The correct information appears in the text, so just remove the statement in the table, where it did not fit nicely anyway. (Curiously, the correct info has been there much longer than the erroneous table entry.) Resolves problem noted by Daniele Varrazzo. In HEAD and 9.1, also do a bit of wordsmithing on other text on the page. 28 November 2011, 18:52:09 UTC
62fa856 Andrew Dunstan 28 November 2011, 12:54:03 UTC Backpatch "Use the preferred version of xsubpp." As requested this is backpatched all the way to release 8.2. 28 November 2011, 12:54:03 UTC
b09fc7c Tom Lane 28 November 2011, 03:27:39 UTC Ensure that whole-row junk Vars are always of composite type. The EvalPlanQual machinery assumes that whole-row Vars generated for the outputs of non-table RTEs will be of composite types. However, for the case where the RTE is a function call returning a scalar type, we were doing the wrong thing, as a result of sharing code with a parser case where the function's scalar output is wanted. (Or at least, that's what that case has done historically; it does seem a bit inconsistent.) To fix, extend makeWholeRowVar's API so that it can support both use-cases. This fixes Belinda Cussen's report of crashes during concurrent execution of UPDATEs involving joins to the result of UNNEST() --- in READ COMMITTED mode, we'd run the EvalPlanQual machinery after a conflicting row update commits, and it was expecting to get a HeapTuple not a scalar datum from the "wholerowN" variable referencing the function RTE. Back-patch to 9.0 where the current EvalPlanQual implementation appeared. In 9.1 and up, this patch also fixes failure to attach the correct collation to the Var generated for a scalar-result case. An example: regression=# select upper(x.*) from textcat('ab', 'cd') x; ERROR: could not determine which collation to use for upper() function 28 November 2011, 03:27:39 UTC
87b0dcf Tom Lane 26 November 2011, 18:01:02 UTC Fix overly-aggressive and inconsistent quoting in OS X start script. Sidar Lopez, per bug #6310, with some additional improvements by me. Back-patch to 9.0, where the issue was introduced. 26 November 2011, 18:01:32 UTC
d1644d9 Bruce Momjian 25 November 2011, 19:34:51 UTC Allow pg_upgrade to upgrade clusters that use exclusion contraints by fixing pg_dump to properly preserve such indexes. Backpatch to 9.1 and 9.0 (where the bug was introduced). 25 November 2011, 19:39:18 UTC
80cbf34 Tom Lane 25 November 2011, 18:58:59 UTC Fix erroneous replay of GIN_UPDATE_META_PAGE WAL records. A simple thinko in ginRedoUpdateMetapage, namely failing to increment a loop counter, led to inserting records into the last pending-list page in the wrong order (the opposite of that intended). So far as I can tell, this would not upset the code that eventually flushes pending items into the main part of the GIN index. But it did break the code that searched the pending list for matches, resulting in transient failure to find matching entries during index lookups, as illustrated in bug #6307 from Maksym Boguk. Back-patch to 8.4 where the incorrect code was introduced. 25 November 2011, 18:59:22 UTC
3c4f293 Tom Lane 19 November 2011, 05:35:29 UTC Avoid floating-point underflow while tracking buffer allocation rate. When the system is idle for awhile after activity, the "smoothed_alloc" state variable in BgBufferSync converges slowly to zero. With standard IEEE float arithmetic this results in several iterations with denormalized values, which causes kernel traps and annoying log messages on some poorly-designed platforms. There's no real need to track such small values of smoothed_alloc, so we can prevent the kernel traps by forcing it to zero as soon as it's too small to be interesting for our purposes. This issue is purely cosmetic, since the iterations don't happen fast enough for the kernel traps to pose any meaningful performance problem, but still it seems worth shutting up the log messages. The kernel log messages were previously reported by a number of people, but kudos to Greg Matthews for tracking down exactly where they were coming from. 19 November 2011, 05:36:16 UTC
acbddf4 Michael Meskes 17 November 2011, 13:07:25 UTC Applied Zoltan's patch to correctly align interval and timestamp data in ecpg's sqlda. 17 November 2011, 13:43:49 UTC
90bbeb1 Robert Haas 16 November 2011, 01:34:47 UTC Don't elide blank lines when accumulating psql command history. This can change the meaning of queries, if the blank line happens to occur in the middle of a quoted literal, as per complaint from Tomas Vondra. Back-patch to all supported branches. 16 November 2011, 01:36:20 UTC
f72baf7 Michael Meskes 13 November 2011, 12:46:45 UTC Applied patch by Zoltan to fix copy&paste bug in ecpg's sqlda handling. 13 November 2011, 12:48:19 UTC
c49130a Tom Lane 10 November 2011, 23:37:00 UTC Throw nice error if server is too old to support psql's \ef or \sf command. Previously, you'd get "function pg_catalog.pg_get_functiondef(integer) does not exist", which is at best rather unprofessional-looking. Back-patch to 8.4 where \ef was introduced. Josh Kupershmidt 10 November 2011, 23:37:00 UTC
019d45e Robert Haas 10 November 2011, 23:00:34 UTC Correct documentation for trace_userlocks. 10 November 2011, 23:01:10 UTC
1d9d7a9 Peter Eisentraut 10 November 2011, 18:52:54 UTC Fix server header file installation with vpath builds Several server header files would not be installed in vpath builds because they live in the build directory. 10 November 2011, 18:55:39 UTC
a062ee4 Heikki Linnakangas 08 November 2011, 20:39:43 UTC Make DatumGetInetP() unpack inet datums with a 1-byte header, and add a new macro, DatumGetInetPP(), that does not. This brings these macros in line with other DatumGet*P() macros. Backpatch to 8.3, where 1-byte header varlenas were introduced. 08 November 2011, 20:45:28 UTC
0ff319d Peter Eisentraut 08 November 2011, 04:49:50 UTC -DLINUX_OOM_ADJ=0 should be in CPPFLAGS, not CFLAGS 08 November 2011, 04:51:01 UTC
d747a45 Tom Lane 07 November 2011, 16:48:53 UTC Fix assorted bugs in contrib/unaccent's configuration file parsing. Make it use t_isspace() to identify whitespace, rather than relying on sscanf which is known to get it wrong on some platform/locale combinations. Get rid of fixed-size buffers. Make it actually continue to parse the file after ignoring a line with untranslatable characters, as was obviously intended. The first of these issues is per gripe from J Smith, though not exactly either of his proposed patches. 07 November 2011, 16:49:17 UTC
b07b2bd Tom Lane 05 November 2011, 03:23:16 UTC Don't assume that a tuple's header size is unchanged during toasting. This assumption can be wrong when the toaster is passed a raw on-disk tuple, because the tuple might pre-date an ALTER TABLE ADD COLUMN operation that added columns without rewriting the table. In such a case the tuple's natts value is smaller than what we expect from the tuple descriptor, and so its t_hoff value could be smaller too. In fact, the tuple might not have a null bitmap at all, and yet our current opinion of it is that it contains some trailing nulls. In such a situation, toast_insert_or_update did the wrong thing, because to save a few lines of code it would use the old t_hoff value as the offset where heap_fill_tuple should start filling data. This did not leave enough room for the new nulls bitmap, with the result that the first few bytes of data could be overwritten with null flag bits, as in a recent report from Hubert Depesz Lubaczewski. The particular case reported requires ALTER TABLE ADD COLUMN followed by CREATE TABLE AS SELECT * FROM ... or INSERT ... SELECT * FROM ..., and further requires that there be some out-of-line toasted fields in one of the tuples to be copied; else we'll not reach the troublesome code. The problem can only manifest in this form in 8.4 and later, because before commit a77eaa6a95009a3441e0d475d1980259d45da072, CREATE TABLE AS or INSERT/SELECT wouldn't result in raw disk tuples getting passed directly to heap_insert --- there would always have been at least a junkfilter in between, and that would reconstitute the tuple header with an up-to-date t_natts and hence t_hoff. But I'm backpatching the tuptoaster change all the way anyway, because I'm not convinced there are no older code paths that present a similar risk. 05 November 2011, 03:23:16 UTC
d8bff79 Peter Eisentraut 04 November 2011, 20:01:35 UTC Fix archive_command example The given archive_command example didn't use %p or %f, which wouldn't really work in practice. 04 November 2011, 20:03:45 UTC
3fbfd40 Tom Lane 03 November 2011, 23:17:59 UTC Fix bogus code in contrib/ tsearch dictionary examples. Both dict_int and dict_xsyn were blithely assuming that whatever memory palloc gives back will be pre-zeroed. This would typically work for just about long enough to run their regression tests, and no longer :-(. The pre-9.0 code in dict_xsyn was even lamer than that, as it would happily give back a pointer to the result of palloc(0), encouraging its caller to access off the end of memory. Again, this would just barely fail to fail as long as memory contained nothing but zeroes. Per a report from Rodrigo Hjort that code based on these examples didn't work reliably. 03 November 2011, 23:17:59 UTC
9b3c35a Tom Lane 03 November 2011, 21:53:26 UTC Fix inline_set_returning_function() to allow multiple OUT parameters. inline_set_returning_function failed to distinguish functions returning generic RECORD (which require a column list in the RTE, as well as run-time type checking) from those with multiple OUT parameters (which do not). This prevented inlining from happening. Per complaint from Jay Levitt. Back-patch to 8.4 where this capability was introduced. 03 November 2011, 21:53:26 UTC
42f7724 Tom Lane 02 November 2011, 17:36:31 UTC Revert "Stop btree indexscans upon reaching nulls in either direction." This reverts commit 7357f92a3ef1faff0ce85f55f3c5a7f4dc820eaa. As pointed out by Naoya Anzai, we need to do more work to make that idea handle end-of-index cases, and it is looking like too much risk for a back-patch. So bug #6278 is only going to be fixed in HEAD. 02 November 2011, 17:36:31 UTC
656bba9 Simon Riggs 02 November 2011, 08:52:59 UTC Derive oldestActiveXid at correct time for Hot Standby. There was a timing window between when oldestActiveXid was derived and when it should have been derived that only shows itself under heavy load. Move code around to ensure correct timing of derivation. No change to StartupSUBTRANS() code, which is where this failed. Bug report by Chris Redekop 02 November 2011, 08:52:59 UTC
ff8451a Simon Riggs 02 November 2011, 08:27:00 UTC Start Hot Standby faster when initial snapshot is incomplete. If the initial snapshot had overflowed then we can start whenever the latest snapshot is empty, not overflowed or as we did already, start when the xmin on primary was higher than xmax of our starting snapshot, which proves we have full snapshot data. Bug report by Chris Redekop 02 November 2011, 08:27:00 UTC
2f55c53 Simon Riggs 02 November 2011, 08:03:21 UTC Fix timing of Startup CLOG and MultiXact during Hot Standby Patch by me, bug report by Chris Redekop, analysis by Florian Pflug 02 November 2011, 08:03:21 UTC
7f797d2 Tom Lane 01 November 2011, 23:48:49 UTC Fix race condition with toast table access from a stale syscache entry. If a tuple in a syscache contains an out-of-line toasted field, and we try to fetch that field shortly after some other transaction has committed an update or deletion of the tuple, there is a race condition: vacuum could come along and remove the toast tuples before we can fetch them. This leads to transient failures like "missing chunk number 0 for toast value NNNNN in pg_toast_2619", as seen in recent reports from Andrew Hammond and Tim Uckun. The design idea of syscache is that access to stale syscache entries should be prevented by relation-level locks, but that fails for at least two cases where toasted fields are possible: ANALYZE updates pg_statistic rows without locking out sessions that might want to plan queries on the same table, and CREATE OR REPLACE FUNCTION updates pg_proc rows without any meaningful lock at all. The least risky fix seems to be an idea that Heikki suggested when we were dealing with a related problem back in August: forcibly detoast any out-of-line fields before putting a tuple into syscache in the first place. This avoids the problem because at the time we fetch the parent tuple from the catalog, we should be holding an MVCC snapshot that will prevent removal of the toast tuples, even if the parent tuple is outdated immediately after we fetch it. (Note: I'm not convinced that this statement holds true at every instant where we could be fetching a syscache entry at all, but it does appear to hold true at the times where we could fetch an entry that could have a toasted field. We will need to be a bit wary of adding toast tables to low-level catalogs that don't have them already.) An additional benefit is that subsequent uses of the syscache entry should be faster, since they won't have to detoast the field. Back-patch to all supported versions. The problem is significantly harder to reproduce in pre-9.0 releases, because of their willingness to flush every entry in a syscache whenever the underlying catalog is vacuumed (cf CatalogCacheFlushRelation); but there is still a window for trouble. 01 November 2011, 23:48:49 UTC
be5531c Magnus Hagander 01 November 2011, 14:44:26 UTC Document that multiple LDAP servers can be specified 01 November 2011, 14:45:22 UTC
7357f92 Tom Lane 31 October 2011, 20:40:16 UTC Stop btree indexscans upon reaching nulls in either direction. The existing scan-direction-sensitive tests were overly complex, and failed to stop the scan in cases where it's perfectly legitimate to do so. Per bug #6278 from Maksym Boguk. Back-patch to 8.3, which is as far back as the patch applies easily. Doesn't seem worth sweating over a relatively minor performance issue in 8.2 at this late date. (But note that this was a performance regression from 8.1 and before, so 8.2 is being left as an outlier.) 31 October 2011, 20:40:16 UTC
5093944 Tom Lane 29 October 2011, 18:31:03 UTC Fix assorted bogosities in cash_in() and cash_out(). cash_out failed to handle multiple-byte thousands separators, as per bug #6277 from Alexander Law. In addition, cash_in didn't handle that either, nor could it handle multiple-byte positive_sign. Both routines failed to support multiple-byte mon_decimal_point, which I did not think was worth changing, but at least now they check for the possibility and fall back to using '.' rather than emitting invalid output. Also, make cash_in handle trailing negative signs, which formerly it would reject. Since cash_out generates trailing negative signs whenever the locale tells it to, this last omission represents a fail-to-reload-dumped-data bug. IMO that justifies patching this all the way back. 29 October 2011, 18:31:03 UTC
0418bea Tom Lane 28 October 2011, 03:09:15 UTC Update docs to point to the timezone library's new home at IANA. The recent unpleasantness with copyrights has accelerated a move that was already in planning. 28 October 2011, 03:09:15 UTC
68b0997 Tom Lane 26 October 2011, 17:02:40 UTC Change FK trigger creation order to better support self-referential FKs. When a foreign-key constraint references another column of the same table, row updates will queue both the PK's ON UPDATE action and the FK's CHECK action in the same event. The ON UPDATE action must execute first, else the CHECK will check a non-final state of the row and possibly throw an inappropriate error, as seen in bug #6268 from Roman Lytovchenko. Now, the firing order of multiple triggers for the same event is determined by the sort order of their pg_trigger.tgnames, and the auto-generated names we use for FK triggers are "RI_ConstraintTrigger_NNNN" where NNNN is the trigger OID. So most of the time the firing order is the same as creation order, and so rearranging the creation order fixes it. This patch will fail to fix the problem if the OID counter wraps around or adds a decimal digit (eg, from 99999 to 100000) while we are creating the triggers for an FK constraint. Given the small odds of that, and the low usage of self-referential FKs, we'll live with that solution in the back branches. A better fix is to change the auto-generated names for FK triggers, but it seems unwise to do that in stable branches because there may be client code that depends on the naming convention. We'll fix it that way in HEAD in a separate patch. Back-patch to all supported branches, since this bug has existed for a long time. 26 October 2011, 17:02:40 UTC
9fbb3ed Tom Lane 23 October 2011, 04:43:52 UTC Don't trust deferred-unique indexes for join removal. The uniqueness condition might fail to hold intra-transaction, and assuming it does can give incorrect query results. Per report from Marti Raudsepp, though this is not his proposed patch. Back-patch to 9.0, where both these features were introduced. In the released branches, add the new IndexOptInfo field to the end of the struct, to try to minimize ABI breakage for third-party code that may be examining that struct. 23 October 2011, 04:43:52 UTC
015cda4 Tom Lane 18 October 2011, 21:11:07 UTC Fix pg_dump to dump casts between auto-generated types. The heuristic for when to dump a cast failed for a cast between table rowtypes, as reported by Frédéric Rejol. Fix it by setting the "dump" flag for such a type the same way as the flag is set for the underlying table or base type. This won't result in the auto-generated type appearing in the output, since setting its objType to DO_DUMMY_TYPE unconditionally suppresses that. But it will result in dumpCast doing what was intended. Back-patch to 8.3. The 8.2 code is rather different in this area, and it doesn't seem worth any risk to fix a corner case that nobody has stumbled on before. 18 October 2011, 21:11:07 UTC
9ca46f5 Tom Lane 15 October 2011, 00:24:32 UTC Fix bugs in information_schema.referential_constraints view. This view was being insufficiently careful about matching the FK constraint to the depended-on primary or unique key constraint. That could result in failure to show an FK constraint at all, or showing it multiple times, or claiming that it depended on a different constraint than the one it really does. Fix by joining via pg_depend to ensure that we find only the correct dependency. Back-patch, but don't bump catversion because we can't force initdb in back branches. The next minor-version release notes should explain that if you need to fix this in an existing installation, you can drop the information_schema schema then re-create it by sourcing $SHAREDIR/information_schema.sql in each database (as a superuser of course). 15 October 2011, 00:24:32 UTC
7ddd5bd Bruce Momjian 12 October 2011, 18:03:18 UTC Modify up/home macro to match standard parameter list; fixes doc build. 12 October 2011, 18:05:29 UTC
606990d Tom Lane 12 October 2011, 17:59:30 UTC Improve documentation of psql's \q command. The documentation neglected to explain its behavior in a script file (it only ends execution of the script, not psql as a whole), and failed to mention the long form \quit either. 12 October 2011, 18:00:07 UTC
55800b6 Bruce Momjian 12 October 2011, 15:48:02 UTC Add Up/Home link to the top of the HTML doc output. Backpatch to 9.0.X and 9.1.X. 12 October 2011, 15:48:02 UTC
9c09e7c Robert Haas 10 October 2011, 17:10:47 UTC Fix typo in docs for libpq keepalives_count option. Shigehiro Honda 10 October 2011, 17:11:43 UTC
c02e52d Heikki Linnakangas 08 October 2011, 08:17:40 UTC Don't let transform_null_equals=on affect CASE foo WHEN NULL ... constructs. transform_null_equals is only supposed to affect "foo = NULL" expressions given directly by the user, not the internal "foo = NULL" expression generated from CASE-WHEN. This fixes bug #6242, reported by Sergey. Backpatch to all supported branches. 08 October 2011, 08:21:04 UTC
b77b601 Robert Haas 06 October 2011, 16:08:59 UTC Make pgstatindex respond to cancel interrupts. A similar problem for pgstattuple() was fixed in April of 2010 by commit 33065ef8bc52253ae855bc959576e52d8a28ba06, but pgstatindex() seems to have been overlooked. Back-patch all the way, as with that commit, though not to 7.4 through 8.1, since those are now EOL. 06 October 2011, 16:10:19 UTC
ddc36df Tom Lane 04 October 2011, 21:00:17 UTC Add sourcefile/sourceline data to EXEC_BACKEND GUC transmission files. This oversight meant that on Windows, the pg_settings view would not display source file or line number information for values coming from postgresql.conf, unless the backend had received a SIGHUP since starting. In passing, also make the error detection in read_nondefault_variables a tad more thorough, and fix it to not lose precision on float GUCs (these changes are already in HEAD as of my previous commit). 04 October 2011, 21:01:06 UTC
f994bf9 Tom Lane 03 October 2011, 16:13:15 UTC ProcedureCreate neglected to record dependencies on default expressions. Thus, an object referenced in a default expression could be dropped while the function remained present. This was unaccountably missed in the original patch to add default parameters for functions. Reported by Pavel Stehule. 03 October 2011, 16:13:46 UTC
b07de20 Magnus Hagander 24 September 2011, 12:34:32 UTC Fix typo 24 September 2011, 12:35:08 UTC
05c4ef6 Magnus Hagander 24 September 2011, 12:29:37 UTC Note that sslmode=require verifies the CA if root cert is present This mode still exists for backwards compatibility, making sslmode=require the same as sslmode=verify-ca when the file is present, but not causing an error when it isn't. Per bug 6189, reported by Srinivas Aji 24 September 2011, 12:29:37 UTC
23f7df5 Tom Lane 24 September 2011, 02:12:36 UTC Fix our mapping of Windows timezones for Central America. We were mapping "Central America Standard Time" to "CST6CDT", which seems entirely wrong, because according to the Olson timezone database noplace in Central America observes daylight savings time on any regular basis --- and certainly not according to the USA DST rules that are implied by "CST6CDT". (Mexico is an exception, but they can be disregarded since they have a separate timezone name in Windows.) So, map this zone name to plain "CST6", which will provide a fixed UTC offset. As written, this patch will also result in mapping "Central America Daylight Time" to CST6. I considered hacking things so that would still map to CST6CDT, but it seems it would confuse win32tzlist.pl to put those two names in separate entries. Since there's little evidence that any such zone name is used in the wild, much less that CST6CDT would be a good match for it, I'm not too worried about what we do with it. Per complaint from Pratik Chirania. 24 September 2011, 02:13:03 UTC
8522403 Tom Lane 22 September 2011, 22:00:48 UTC Stamp 9.0.5. 22 September 2011, 22:00:48 UTC
94a4195 Tom Lane 22 September 2011, 21:39:25 UTC Update release notes for 9.1.1, 9.0.5, 8.4.9, 8.3.16, 8.2.22. Man, we fixed a lotta bugs since April. 22 September 2011, 21:40:22 UTC
back to top