https://github.com/postgres/postgres

sort by:
Revision Author Date Message Commit Date
c47f643 Stamp 9.1.7. 03 December 2012, 20:19:35 UTC
86e006d Update release notes for 9.2.2, 9.1.7, 9.0.11, 8.4.15, 8.3.22. 03 December 2012, 20:10:10 UTC
13632b0 Revert "Add mode where contrib installcheck runs each module in a separately named database." This reverts commit 513e546a6e75b0a79c3102ce22c583ccd1053ac6. 03 December 2012, 20:03:15 UTC
3c4eec4 Avoid holding vmbuffer pin after VACUUM. During VACUUM if we pause to perform a cycle of index cleanup we drop the vmbuffer pin, so we should do the same thing when heap scan completes. This avoids holding vmbuffer pin across the main index cleanup in VACUUM, which could be minutes or hours longer than necessary for correctness. Bug report and suggested fix from Pavan Deolasee 03 December 2012, 18:55:42 UTC
e0aad34 Fix documentation of path(polygon) function. Obviously, this returns type "path", but somebody made a copy-and-pasteo long ago. Dagfinn Ilmari Mannsåker 03 December 2012, 16:08:59 UTC
04a210b Translation updates 03 December 2012, 12:53:51 UTC
513e546 Add mode where contrib installcheck runs each module in a separately named database. Normally each module is tested in aq database named contrib_regression, which is dropped and recreated at the beginhning of each pg_regress run. This mode, enabled by adding USE_MODULE_DB=1 to the make command line, runs most modules in a database with the module name embedded in it. This will make testing pg_upgrade on clusters with the contrib modules a lot easier. Still to be done: adapt to the MSVC build system. Backpatch to 9.0, which is the earliest version it is reasonably possible to test upgrading from. 02 December 2012, 22:29:30 UTC
31ab893 Update time zone data files to tzdata release 2012j. DST law changes in Cuba, Israel, Jordan, Libya, Palestine, Western Samoa, and portions of Brazil. 02 December 2012, 21:35:58 UTC
7e487c1 Recommend triggers, not rules, in the CREATE VIEW reference page. We've generally recommended use of INSTEAD triggers over rules since that feature was added; but this old text in the CREATE VIEW reference page didn't get the memo. Noted by Thomas Kellerer. 02 December 2012, 21:18:18 UTC
d08fd1f Don't advance checkPoint.nextXid near the end of a checkpoint sequence. This reverts commit c11130690d6dca64267201a169cfb38c1adec5ef in favor of actually fixing the problem: namely, that we should never have been modifying the checkpoint record's nextXid at this point to begin with. The nextXid should match the state as of the checkpoint's logical WAL position (ie the redo point), not the state as of its physical position. It's especially bogus to advance it in some wal_levels and not others. In any case there is no need for the checkpoint record to carry the same nextXid shown in the XLOG_RUNNING_XACTS record just emitted by LogStandbySnapshot, as any replay operation will already have adopted that value as current. This fixes bug #7710 from Tarvi Pillessaar, and probably also explains bug #6291 from Daniel Farina, in that if a checkpoint were in progress at the instant of XID wraparound, the epoch bump would be lost as reported. (And, of course, these days there's at least a 50-50 chance of a checkpoint being in progress at any given instant.) Diagnosed by me and independently by Andres Freund. Back-patch to all branches supporting hot standby. 02 December 2012, 20:20:08 UTC
973c011 XidEpoch++ if wraparound during checkpoint. If wal_level = hot_standby we update the checkpoint nextxid, though in the case where a wraparound occurred half-way through a checkpoint we would neglect updating the epoch also. Updating the nextxid is arguably the wrong thing to do, but changing that may introduce subtle bugs into hot standby startup, while updating the value doesn't cause any known bugs yet. Minimal fix now to HEAD and backbranches, wider fix later in HEAD. Bug reported in #6291 by Daniel Farina and slightly differently in Cause analysis and recommended fixes from Tom Lane and Andres Freund. Applied patch is minimal version of Andres Freund's work. 02 December 2012, 15:01:44 UTC
a7c5309 Fix psql crash while parsing SQL file whose encoding is different from client encoding and the client encoding is not *safe* one. Such an example is, file encoding is UTF-8 and client encoding SJIS. Patch contributed by Jiang Guiqing. 02 December 2012, 12:21:40 UTC
647b1bc Prevent passing gmake's environment variables down through pg_regress. When we do "make install" to create a temp installation, we don't want that instance of make to try to communicate with any instance of make that might be calling us. This is known to cause problems if the upper make has a -jN flag, and in principle could cause problems even without that. Unset the relevant environment variables to prevent such issues. Andres Freund 01 December 2012, 22:24:01 UTC
04f91ae Make sure sharedir/extension/ directory is created when needed. The previous coding worked as long as MODULEDIR wasn't set explicitly, because we create sharedir/$(datamoduledir) and the default value of that is "extension". But if some other value is specified for MODULEDIR then the installation directory needed for the control file wasn't made. Cédric Villemain 01 December 2012, 21:04:50 UTC
1b4359b doc: Fix broken links to DocBook wiki 01 December 2012, 06:53:28 UTC
2b96c32 Take buffer lock while inspecting btree index pages in contrib/pageinspect. It's not safe to examine a shared buffer without any lock. 30 November 2012, 22:02:39 UTC
df1aa46 Add missing buffer lock acquisition in GetTupleForTrigger(). If we had not been holding buffer pin continuously since the tuple was initially fetched by the UPDATE or DELETE query, it would be possible for VACUUM or a page-prune operation to move the tuple while we're trying to copy it. This would result in a garbage "old" tuple value being passed to an AFTER ROW UPDATE or AFTER ROW DELETE trigger. The preconditions for this are somewhat improbable, and the timing constraints are very tight; so it's not so surprising that this hasn't been reported from the field, even though the bug has been there a long time. Problem found by Andres Freund. Back-patch to all active branches. 30 November 2012, 18:56:04 UTC
c6a91c9 Produce a more useful error message for over-length Unix socket paths. The length of a socket path name is constrained by the size of struct sockaddr_un, and there's not a lot we can do about it since that is a kernel API. However, it would be a good thing if we produced an intelligible error message when the user specifies a socket path that's too long --- and getaddrinfo's standard API is too impoverished to do this in the natural way. So insert explicit tests at the places where we construct a socket path name. Now you'll get an error that makes sense and even tells you what the limit is, rather than something generic like "Non-recoverable failure in name resolution". Per trouble report from Jeremy Drake and a fix idea from Andrew Dunstan. 30 November 2012, 00:57:17 UTC
6f9a9da Correctly init/deinit recovery xact environment. Previously we performed VirtualXactLockTableInsert but didn't set MyProc->lxid for Startup process. pg_locks now correctly shows "1/1" for vxid of Startup process during Hot Standby. At end of Hot Standby the Virtual Transaction was not deleted, leading to problems after promoting to normal running for some commands, such as CREATE INDEX CONCURRENTLY. 29 November 2012, 23:52:17 UTC
1da5bef Fix assorted bugs in CREATE INDEX CONCURRENTLY. This patch changes CREATE INDEX CONCURRENTLY so that the pg_index flag changes it makes without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. This is a subset of a patch already applied in 9.2 and HEAD. Back-patch into all earlier supported branches. Tom Lane and Andres Freund 29 November 2012, 19:51:46 UTC
381c3b8 When processing nested structure pointer variables ecpg always expected an array datatype which of course is wrong. Applied patch by Muhammad Usama <m.usama@gmail.com> to fix this. 29 November 2012, 16:15:02 UTC
bdceb86 Fix SELECT DISTINCT with index-optimized MIN/MAX on inheritance trees. In a query such as "SELECT DISTINCT min(x) FROM tab", the DISTINCT is pretty useless (there being only one output row), but nonetheless it shouldn't fail. But it could fail if "tab" is an inheritance parent, because planagg.c's code for fixing up equivalence classes after making the index-optimized MIN/MAX transformation wasn't prepared to find child-table versions of the aggregate expression. The least ugly fix seems to be to add an option to mutate_eclass_expressions() to skip child-table equivalence class members, which aren't used anymore at this stage of planning so it's not really necessary to fix them. Since child members are ignored in many cases already, it seems plausible for mutate_eclass_expressions() to have an option to ignore them too. Per bug #7703 from Maxim Boguk. Back-patch to 9.1. Although the same code exists before that, it cannot encounter child-table aggregates AFAICS, because the index optimization transformation cannot succeed on inheritance trees before 9.1 (for lack of MergeAppend). 26 November 2012, 17:58:20 UTC
38b38fb pg_stat_replication.sync_state was displayed incorrectly at page boundary. XLogRecPtrIsInvalid() only checks the xrecoff field, which is correct when checking if a WAL record could legally begin at the given position, but WAL sending can legally be paused at a page boundary, in which case xrecoff is 0. Use XLByteEQ(..., InvalidXLogRecPtr) instead, which checks that both xlogid and xrecoff are 0. 9.3 doesn't have this problem because XLogRecPtr is now a single 64-bit integer, so XLogRecPtrIsInvalid() does the right thing. Apply to 9.2, and 9.1 where pg_stat_replication view was introduced. Kyotaro HORIGUCHI, reviewed by Fujii Masao. 23 November 2012, 17:14:41 UTC
806e6d1 Fix pg_resetxlog to use correct path to postmaster.pid. Since we've already chdir'd into the data directory, the file should be referenced as just "postmaster.pid", without prefixing the directory path. This is harmless in the normal case where an absolute PGDATA path is used, but quite dangerous if a relative path is specified, since the program might then fail to notice an active postmaster. Reported by Hari Babu. This got broken in my commit eb5949d190e80360386113fde0f05854f0c9824d, so patch all active versions. 22 November 2012, 16:24:58 UTC
db3658b Avoid bogus "out-of-sequence timeline ID" errors in standby-mode. When startup process opens a WAL segment after replaying part of it, it validates the first page on the WAL segment, even though the page it's really interested in later in the file. As part of the validation, it checks that the TLI on the page header is >= the TLI it saw on the last page it read. If the segment contains a timeline switch, and we have already replayed it, and then re-open the WAL segment (because of streaming replication got disconnected and reconnected, for example), the TLI check will fail when the first page is validated. Fix that by relaxing the TLI check when re-opening a WAL segment. Backpatch to 9.0. Earlier versions had the same code, but before standby mode was introduced in 9.0, recovery never tried to re-read a segment after partially replaying it. Reported by Amit Kapila, while testing a new feature. 22 November 2012, 09:37:22 UTC
866f2dd Don't launch new child processes after we've been told to shut down. Once we've received a shutdown signal (SIGINT or SIGTERM), we should not launch any more child processes, even if we get signals requesting such. The normal code path for spawning backends has always understood that, but the postmaster's infrastructure for hot standby and autovacuum didn't get the memo. As reported by Hari Babu in bug #7643, this could lead to failure to shut down at all in some cases, such as when SIGINT is received just before the startup process sends PMSIGNAL_RECOVERY_STARTED: we'd launch a bgwriter and checkpointer, and then those processes would have no idea that they ought to quit. Similarly, launching a new autovacuum worker would result in waiting till it finished before shutting down. Also, switch the order of the code blocks in reaper() that detect startup process crash versus shutdown termination. Once we've sent it a signal, we should not consider that exit(1) is surprising. This is just a cosmetic fix since shutdown occurs correctly anyway, but better not to log a phony complaint about startup process crash. Back-patch to 9.0. Some parts of this might be applicable before that, but given the lack of prior complaints I'm not going to worry too much about older branches. 21 November 2012, 20:18:47 UTC
4387cc9 Improve handling of INT_MIN / -1 and related cases. Some platforms throw an exception for this division, rather than returning a necessarily-overflowed result. Since we were testing for overflow after the fact, an exception isn't nice. We can avoid the problem by treating division by -1 as negation. Add some regression tests so that we'll find out if any compilers try to optimize away the overflow check conditions. Back-patch of commit 1f7cb5c30983752ff8de833de30afcaee63536d0. Per discussion with Xi Wang, though this is different from the patch he submitted. 20 November 2012, 02:21:40 UTC
fe838e5 Limit values of archive_timeout, post_auth_delay, auth_delay.milliseconds. The previous definitions of these GUC variables allowed them to range up to INT_MAX, but in point of fact the underlying code would suffer overflows or other errors with large values. Reduce the maximum values to something that won't misbehave. There's no apparent value in working harder than this, since very large delays aren't sensible for any of these. (Note: the risk with archive_timeout is that if we're late checking the state, the timestamp difference it's being compared to might overflow. So we need some amount of slop; the choice of INT_MAX/2 is arbitrary.) Per followup investigation of bug #7670. Although this isn't a very significant fix, might as well back-patch. 18 November 2012, 22:15:16 UTC
e9ad86c Fix the int8 and int2 cases of (minimum possible integer) % (-1). The correct answer for this (or any other case with arg2 = -1) is zero, but some machines throw a floating-point exception instead of behaving sanely. Commit f9ac414c35ea084ff70c564ab2c32adb06d5296f dealt with this in int4mod, but overlooked the fact that it also happens in int8mod (at least on my Linux x86_64 machine). Protect int2mod as well; it's not clear whether any machines fail there (mine does not) but since the test is so cheap it seems better safe than sorry. While at it, simplify the original guard in int4mod: we need only check for arg2 == -1, we don't need to check arg1 explicitly. Xi Wang, with some editing by me. 14 November 2012, 22:30:07 UTC
68a8ea6 Fix memory leaks in record_out() and record_send(). record_out() leaks memory: it fails to free the strings returned by the per-column output functions, and also is careless about detoasted values. This results in a query-lifespan memory leakage when returning composite values to the client, because printtup() runs the output functions in the query-lifespan memory context. Fix it to handle these issues the same way printtup() does. Also fix a similar leakage in record_send(). (At some point we might want to try to run output functions in shorter-lived memory contexts, so that we don't need a zero-leakage policy for them. But that would be a significantly more invasive patch, which doesn't seem like material for back-patching.) In passing, use appendStringInfoCharMacro instead of appendStringInfoChar in the innermost data-copying loop of record_out, to try to shave a few cycles from this function's runtime. Per trouble report from Carlos Henrique Reimer. Back-patch to all supported versions. 13 November 2012, 19:45:55 UTC
d0d58f7 Clarify docs on hot standby lock release Andres Freund and Simon Riggs 13 November 2012, 18:58:05 UTC
634e148 Fix multiple problems in WAL replay. Most of the replay functions for WAL record types that modify more than one page failed to ensure that those pages were locked correctly to ensure that concurrent queries could not see inconsistent page states. This is a hangover from coding decisions made long before Hot Standby was added, when it was hardly necessary to acquire buffer locks during WAL replay at all, let alone hold them for carefully-chosen periods. The key problem was that RestoreBkpBlocks was written to hold lock on each page restored from a full-page image for only as long as it took to update that page. This was guaranteed to break any WAL replay function in which there was any update-ordering constraint between pages, because even if the nominal order of the pages is the right one, any mixture of full-page and non-full-page updates in the same record would result in out-of-order updates. Moreover, it wouldn't work for situations where there's a requirement to maintain lock on one page while updating another. Failure to honor an update ordering constraint in this way is thought to be the cause of bug #7648 from Daniel Farina: what seems to have happened there is that a btree page being split was rewritten from a full-page image before the new right sibling page was written, and because lock on the original page was not maintained it was possible for hot standby queries to try to traverse the page's right-link to the not-yet-existing sibling page. To fix, get rid of RestoreBkpBlocks as such, and instead create a new function RestoreBackupBlock that restores just one full-page image at a time. This function can be invoked by WAL replay functions at the points where they would otherwise perform non-full-page updates; in this way, the physical order of page updates remains the same no matter which pages are replaced by full-page images. We can then further adjust the logic in individual replay functions if it is necessary to hold buffer locks for overlapping periods. A side benefit is that we can simplify the handling of concurrency conflict resolution by moving that code into the record-type-specfic functions; there's no more need to contort the code layout to keep conflict resolution in front of the RestoreBkpBlocks call. In connection with that, standardize on zero-based numbering rather than one-based numbering for referencing the full-page images. In HEAD, I removed the macros XLR_BKP_BLOCK_1 through XLR_BKP_BLOCK_4. They are still there in the header files in previous branches, but are no longer used by the code. In addition, fix some other bugs identified in the course of making these changes: spgRedoAddNode could fail to update the parent downlink at all, if the parent tuple is in the same page as either the old or new split tuple and we're not doing a full-page image: it would get fooled by the LSN having been advanced already. This would result in permanent index corruption, not just transient failure of concurrent queries. Also, ginHeapTupleFastInsert's "merge lists" case failed to mark the old tail page as a candidate for a full-page image; in the worst case this could result in torn-page corruption. heap_xlog_freeze() was inconsistent about using a cleanup lock or plain exclusive lock: it did the former in the normal path but the latter for a full-page image. A plain exclusive lock seems sufficient, so change to that. Also, remove gistRedoPageDeleteRecord(), which has been dead code since VACUUM FULL was rewritten. Back-patch to 9.0, where hot standby was introduced. Note however that 9.0 had a significantly different WAL-logging scheme for GIST index updates, and it doesn't appear possible to make that scheme safe for concurrent hot standby queries, because it can leave inconsistent states in the index even between WAL records. Given the lack of complaints from the field, we won't work too hard on fixing that branch. 13 November 2012, 03:05:21 UTC
f8ffe62 Check for stack overflow in transformSetOperationTree(). Since transformSetOperationTree() recurses, it can be driven to stack overflow with enough UNION/INTERSECT/EXCEPT clauses in a query. Add a check to ensure it fails cleanly instead of crashing. Per report from Matthew Gerber (though it's not clear whether this is the only thing going wrong for him). Historical note: I think the reasoning behind not putting a check here in the beginning was that the check in transformExpr() ought to be sufficient to guard the whole parser. However, because transformSetOperationTree() recurses all the way to the bottom of the set-operation tree before doing any analysis of the statement's expressions, that check doesn't save it. 12 November 2012, 00:56:21 UTC
1458f0f XSLT stylesheet: Add slash to directory name Some versions of the XSLT stylesheets don't handle the missing slash correctly (they concatenate directory and file name without the slash). This might never have worked correctly. 09 November 2012, 04:58:36 UTC
f43ca3c Fix handling of inherited check constraints in ALTER COLUMN TYPE. This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches. 05 November 2012, 18:36:26 UTC
efa81e3 Fix bogus handling of $(X) (i.e., ".exe") in isolationtester Makefile. I'm not sure why commit 1eb1dde049ccfffc42c80c2bcec14155c58bcc1f seems to have made this start to fail on Cygwin when it never did before --- but nonetheless, the coding was pretty bogus, and unlike the way we handle $(X) anywhere else. Per buildfarm. 01 November 2012, 23:49:02 UTC
c22acf4 Document that TCP keepalive settings read as 0 on Unix-socket connections. Per bug #7631 from Rob Johnson. The code is operating as designed, but the docs didn't explain it. 31 October 2012, 18:26:40 UTC
6522590 Fix ALTER EXTENSION / SET SCHEMA In its original conception, it was leaving some objects into the old schema, but without their proper pg_depend entries; this meant that the old schema could be dropped, causing future pg_dump calls to fail on the affected database. This was originally reported by Jeff Frost as #6704; there have been other complaints elsewhere that can probably be traced to this bug. To fix, be more consistent about altering a table's subsidiary objects along the table itself; this requires some restructuring in how tables are relocated when altering an extension -- hence the new AlterTableNamespaceInternal routine which encapsulates it for both the ALTER TABLE and the ALTER EXTENSION cases. There was another bug lurking here, which was unmasked after fixing the previous one: certain objects would be reached twice via the dependency graph, and the second attempt to move them would cause the entire operation to fail. Per discussion, it seems the best fix for this is to do more careful tracking of objects already moved: we now maintain a list of moved objects, to avoid attempting to do it twice for the same object. Authors: Alvaro Herrera, Dimitri Fontaine Reviewed by Tom Lane 31 October 2012, 13:49:14 UTC
ff8f710 Prefer actual constants to pseudo-constants in equivalence class machinery. generate_base_implied_equalities_const() should prefer plain Consts over other em_is_const eclass members when choosing the "pivot" value that all the other members will be equated to. This makes it more likely that the generated equalities will be useful in constraint-exclusion proofs. Per report from Rushabh Lathia. 26 October 2012, 18:19:47 UTC
5110a96 In pg_dump, dump SEQUENCE SET items in the data not pre-data section. Represent a sequence's current value as a separate TableDataInfo dumpable object, so that it can be dumped within the data section of the archive rather than in pre-data. This fixes an undesirable inconsistency between the meanings of "--data-only" and "--section=data", and also fixes dumping of sequences that are marked as extension configuration tables, as per a report from Marko Kreen back in July. The main cost is that we do one more SQL query per sequence, but that's probably not very meaningful in most databases. Back-patch to 9.1, since it has the extension configuration issue even though not the --section switch. 26 October 2012, 16:12:53 UTC
f01936f Prevent parser from believing that views have system columns. Views should not have any pg_attribute entries for system columns. However, we forgot to remove such entries when converting a table to a view. This could lead to crashes later on, if someone attempted to reference such a column, as reported by Kohei KaiGai. This problem is corrected properly in HEAD (by removing the pg_attribute entries during conversion), but in the back branches we need to defend against existing mis-converted views. This fix costs us an extra syscache lookup per system column reference, which is annoying but probably not really measurable in the big scheme of things. 24 October 2012, 18:53:58 UTC
d01a744 Fix hash_search to avoid corruption of the hash table on out-of-memory. An out-of-memory error during expand_table() on a palloc-based hash table would leave a partially-initialized entry in the table. This would not be harmful for transient hash tables, since they'd get thrown away anyway at transaction abort. But for long-lived hash tables, such as the relcache hash, this would effectively corrupt the table, leading to crash or other misbehavior later. To fix, rearrange the order of operations so that table enlargement is attempted before we insert a new entry, rather than after adding it to the hash table. Problem discovered by Hitoshi Harada, though this is a bit different from his proposed patch. 19 October 2012, 19:24:15 UTC
823f83d Fix ruleutils to print "INSERT INTO foo DEFAULT VALUES" correctly. Per bug #7615 from Marko Tiikkaja. Apparently nobody ever tried this case before ... 19 October 2012, 17:40:05 UTC
d2a5f32 Further tweaking of the readfile() function in pg_ctl. Don't leak a file descriptor if the file is empty or we can't read its size. Expect there to be a newline at the end of the last line, too. If there isn't, ignore anything after the last newline. This makes it a tiny bit more robust in case the file is appended to concurrently, so that we don't return the last line if it hasn't been fully written yet. And this makes the code a bit less obscure, anyway. Per Tom Lane's suggestion. Backpatch to all supported branches. 18 October 2012, 19:30:42 UTC
447dad7 Fix planning of non-strict equivalence clauses above outer joins. If a potential equivalence clause references a variable from the nullable side of an outer join, the planner needs to take care that derived clauses are not pushed to below the outer join; else they may use the wrong value for the variable. (The problem arises only with non-strict clauses, since if an upper clause can be proven strict then the outer join will get simplified to a plain join.) The planner attempted to prevent this type of error by checking that potential equivalence clauses aren't outerjoin-delayed as a whole, but actually we have to check each side separately, since the two sides of the clause will get moved around separately if it's treated as an equivalence. Bugs of this type can be demonstrated as far back as 7.4, even though releases before 8.3 had only a very ad-hoc notion of equivalence clauses. In addition, we neglected to account for the possibility that such clauses might have nonempty nullable_relids even when not outerjoin-delayed; so the equivalence-class machinery lacked logic to compute correct nullable_relids values for clauses it constructs. This oversight was harmless before 9.2 because we were only using RestrictInfo.nullable_relids for OR clauses; but as of 9.2 it could result in pushing constructed equivalence clauses to incorrect places. (This accounts for bug #7604 from Bill MacArthur.) Fix the first problem by adding a new test check_equivalence_delay() in distribute_qual_to_rels, and fix the second one by adding code in equivclass.c and called functions to set correct nullable_relids for generated clauses. Although I believe the second part of this is not currently necessary before 9.2, I chose to back-patch it anyway, partly to keep the logic similar across branches and partly because it seems possible we might find other reasons why we need valid values of nullable_relids in the older branches. Add regression tests illustrating these problems. In 9.0 and up, also add test cases checking that we can push constants through outer joins, since we've broken that optimization before and I nearly broke it again with an overly simplistic patch for this problem. 18 October 2012, 16:29:00 UTC
473320e Close un-owned SMgrRelations at transaction end. If an SMgrRelation is not "owned" by a relcache entry, don't allow it to live past transaction end. This design allows the same SMgrRelation to be used for blind writes of multiple blocks during a transaction, but ensures that we don't hold onto such an SMgrRelation indefinitely. Because an SMgrRelation typically corresponds to open file descriptors at the fd.c level, leaving it open when there's no corresponding relcache entry can mean that we prevent the kernel from reclaiming deleted disk space. (While CacheInvalidateSmgr messages usually fix that, there are cases where they're not issued, such as DROP DATABASE. We might want to add some more sinval messaging for that, but I'd be inclined to keep this type of logic anyway, since allowing VFDs to accumulate indefinitely for blind-written relations doesn't seem like a good idea.) This code replaces a previous attempt towards the same goal that proved to be unreliable. Back-patch to 9.1 where the previous patch was added. 17 October 2012, 16:38:33 UTC
cacb652 Revert "Use "transient" files for blind writes, take 2". This reverts commit fba105b1099f4f5fa7283bb17cba6fed2baa8d0c. That approach had problems with the smgr-level state not tracking what we really want to happen, and with the VFD-level state not tracking the smgr-level state very well either. In consequence, it was still possible to hold kernel file descriptors open for long-gone tables (as in recent report from Tore Halset), and yet there were also cases of FDs being closed undesirably soon. A replacement implementation will follow. 17 October 2012, 16:37:20 UTC
f34d1fa Fix typo in previous commit 17 October 2012, 08:20:42 UTC
3877b1f Clarify hash index caution and copy to CREATE INDEX docs 17 October 2012, 07:27:27 UTC
2883674 Fix race condition in pg_ctl reading postmaster.pid. If postmaster changed postmaster.pid while pg_ctl was reading it, pg_ctl could overrun the buffer it allocated for the file. Fix by reading the whole file to memory with one read() call. initdb contains an identical copy of the readfile() function, but the files that initdb reads are static, not modified concurrently. Nevertheless, add a simple bounds-check there, if only to silence static analysis tools. Per report from Dave Vitek. Backpatch to all supported branches. 15 October 2012, 07:54:40 UTC
eb5e0d8 Split up process latch initialization for more-fail-soft behavior. In the previous coding, new backend processes would attempt to create their self-pipe during the OwnLatch call in InitProcess. However, pipe creation could fail if the kernel is short of resources; and the system does not recover gracefully from a FATAL error right there, since we have armed the dead-man switch for this process and not yet set up the on_shmem_exit callback that would disarm it. The postmaster then forces an unnecessary database-wide crash and restart, as reported by Sean Chittenden. There are various ways we could rearrange the code to fix this, but the simplest and sanest seems to be to split out creation of the self-pipe into a new function InitializeLatchSupport, which must be called from a place where failure is allowed. For most processes that gets called in InitProcess or InitAuxiliaryProcess, but processes that don't call either but still use latches need their own calls. Back-patch to 9.1, which has only a part of the latch logic that 9.2 and HEAD have, but nonetheless includes this bug. 15 October 2012, 03:00:07 UTC
de31ea9 Fix cross-type case in partial row matching for hashed subplans. When hashing a subplan like "WHERE (a, b) NOT IN (SELECT x, y FROM ...)", findPartialMatch() attempted to match rows using the hashtable's internal equality operators, which of course are for x and y's datatypes. What we need to use are the potentially cross-type operators for a=x, b=y, etc. Failure to do that leads to wrong answers or even crashes. The scope for problems is limited to cases where we have different types with compatible hash functions (else we'd not be using a hashed subplan), but for example int4 vs int8 can cause the problem. Per bug #7597 from Bo Jensen. This has been wrong since the hashed-subplan code was written, so patch all the way back. 11 October 2012, 16:21:09 UTC
bd0ef30 Fix PGXS support for building loadable modules on AIX. Building a shlib on AIX requires use of the mkldexport.sh script, but we failed to install that, preventing its use from non-source-tree contexts. Also, Makefile.aix had the wrong idea about where to find the installed copy of the postgres.imp symbol file used by AIX. Per report from John Pierce. Patch all the way back, since this has been broken since the beginning of PGXS. 10 October 2012, 01:04:15 UTC
bb3aa7a Fix lo_import and lo_export to return useful error messages more often. I found that these functions tend to return -1 while leaving an empty error message string in the PGconn, if they suffer some kind of I/O error on the file. The reason is that lo_close, which thinks it's executed a perfectly fine SQL command, clears the errorMessage. The minimum-change workaround is to reorder operations here so that we don't fill the errorMessage until after lo_close. 09 October 2012, 01:52:48 UTC
a883c02 Fix lo_export usage in example programs. lo_export returns -1, not zero, on failure. 09 October 2012, 01:18:57 UTC
3c85670 Say ANALYZE, not VACUUM, in error message on analyze in hot standby. Tomonaru Katsumata 08 October 2012, 11:20:56 UTC
8ebe888 Removed sentence about not being able to retrieve more than one row at a time, because it is not correct. 05 October 2012, 15:06:50 UTC
856ce0f Fixed test for array boundary. Instead of continuing if the next character is not an array boundary get_data() used to continue only on finding a boundary so it was not able to read any element after the first. 05 October 2012, 15:06:44 UTC
6c33084 Fix permissions explanations in CREATE DATABASE and CREATE SCHEMA docs. These reference pages still claimed that you have to be superuser to create a database or schema owned by a different role. That was true before 8.1, but it was changed in commits aa1110624c08298393dfce996f7b21809d98d3fd and f91370cd2faf1fd35a1ac74d84652a85ed841919 to allow assignment of ownership to any role you are a member of. However, at the time we were thinking of that primarily as a change to the ALTER OWNER rules, so the need to touch these two CREATE ref pages got missed. 04 October 2012, 17:41:09 UTC
412a429 REASSIGN OWNED: consider grants on tablespaces, too Apparently this was considered in the original code (see commit cec3b0a9) but I failed to notice that such entries would always be skipped by the database check at the start of the loop. Per bugs #7578 by Nikolay, #6116 by tushar.qa@gmail.com. 03 October 2012, 15:29:12 UTC
6c00b2b Fix access past end of string in date parsing. This affects date_in(), and a couple of other funcions that use DecodeDate(). Hitoshi Harada 02 October 2012, 07:47:39 UTC
d617b28 Fix bugs in "restore.sql" script emitted in pg_dump tar output. The tar output module did some very ugly and ultimately incorrect hacking on COPY commands to try to get them to work in the context of restoring a deconstructed tar archive. In particular, it would fail altogether for table names containing any upper-case characters, since it smashed the command string to lower-case before modifying it (and, just to add insult to injury, did that in a way that would fail in multibyte encodings). I don't see any particular value in being flexible about the case of the command keywords, since the string will just have been created by dumpTableData, so let's get rid of the whole case-folding thing. Also, it doesn't seem to meet the POLA for the script to restore data only in COPY mode, so add \i commands to make it have comparable behavior in --inserts mode. Noted while looking at the tar-output code in connection with Brian Weaver's patch. 29 September 2012, 21:56:50 UTC
dfa6eda Fix tar files emitted by pg_basebackup to be POSIX conformant. Back-patch portions of commit 05b555d12bc2ad0d581f48a12b45174db41dc10d. There doesn't seem to be any reason not to fix pg_basebackup fully, but we can't change pg_dump's "magic" string without breaking older versions of pg_restore. Instead, just patch pg_restore to accept either version of the magic string, in hopes of avoiding compatibility problems when 9.3 comes out. I also fixed pg_dump to write the correct 2-block EOF marker, since that won't create a compatibility problem with pg_restore and it could help with some versions of tar. Brian Weaver and Tom Lane 28 September 2012, 19:35:51 UTC
bc99397 Fix examples of how to use "su" while starting the server. The syntax "su -c 'command' username" is not accepted by all versions of su, for example not OpenBSD's. More portable is "su username -c 'command'". So change runtime.sgml to recommend that syntax. Also, add a -D switch to the OpenBSD example script, for consistency with other examples. Per Denis Lapshin and Gábor Hidvégi. 25 September 2012, 17:53:01 UTC
04a37a5 Stamp 9.1.6. 19 September 2012, 21:50:31 UTC
793664d Update release notes for 9.2.1, 9.1.6, 9.0.10, 8.4.14, 8.3.21. 19 September 2012, 21:38:53 UTC
1dd03b5 Update time zone data files to tzdata release 2012f. DST law changes in Fiji. 19 September 2012, 14:45:22 UTC
d4e1ca2 Translation updates 19 September 2012, 04:03:54 UTC
6750375 pg_upgrade: Remove check for pg_config It is no longer used, but was still being checked for. bug #7548 from Reinhard Max 19 September 2012, 02:05:14 UTC
3440583 Provide adequate documentation of the "table_name *" notation. Somewhere along the line, somebody decided to remove all trace of this notation from the documentation text. It was still in the command syntax synopses, or at least some of them, but with no indication what it meant. This will not do, as evidenced by the confusion apparent in bug #7543; even if the notation is now unnecessary, people will find it in legacy SQL code and need to know what it does. 17 September 2012, 18:59:38 UTC
25560fd Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown checkpoint. Recovery code documents clearly that a shutdown checkpoint is executed at end of recovery - a shutdown checkpoint WAL record is written but the buffer manager had been altered to treat end of recovery as a normal checkpoint. This bug exacerbates the bufmgr relpersistence bug. Bug spotted by Andres Freund, patch by me. 16 September 2012, 18:55:27 UTC
5752e1b Fix documentation reference to maximum allowed for autovacuum_freeze_max_age. The documentation mentioned setting autovacuum_freeze_max_age to "its maximum allowed value of a little less than two billion". This led to a post asking about the exact maximum allowed value, which is precisely two billion, not "a little less". Based on question by Radovan Jablonovsky. Backpatch to 8.3. 16 September 2012, 17:20:35 UTC
87802a1 Back-patch fix and test case for bug #7516. Back-patch commits 9afc6481117d2dd936e752da0424a2b6b05f6459 and b8fbbcf37f22c5e8361da939ad0fc4be18a34ca9. The first of these is really a minor code cleanup to save a few cycles, but it turns out to provide a workaround for the misoptimization problem described in bug #7516. The second commit adds a regression test case. Back-patch the fix to all active branches. The test case only works as far back as 9.0, because it relies on plpgsql which isn't installed by default before that. (I didn't have success modifying it into an all-plperl form that still provoked a crash, though this may just reflect my lack of Perl-fu.) 14 September 2012, 15:50:06 UTC
fef2c17 Properly set relpersistence for fake relcache entries. This can result in buffers failing to be properly flushed at checkpoint time, leading to data loss. Report, diagnosis, and patch by Jeff Davis. 14 September 2012, 13:39:10 UTC
df4234d Fix typo: lexemes misspelled in full text search docs. Dan Scott Backpatch original commit 4bc0d2e2cfa8ac523524dccf6f849989c6739083 to 9.1 12 September 2012, 12:41:55 UTC
bd371ea Fix logical errors in tsquery selectivity estimation for prefix queries. I made multiple errors in commit 97532f7c29468010b87e40a04f8daa3eb097f654, stemming mostly from failure to think about the available frequency data as being element frequencies not value frequencies (so that occurrences of different elements are not mutually exclusive). This led to sillinesses such as estimating that "word" would match more rows than "word:*". The choice to clamp to a minimum estimate of DEFAULT_TS_MATCH_SEL also seems pretty ill-considered in hindsight, as it would frequently result in an estimate much larger than the available data suggests. We do need some sort of clamp, since a pattern not matching any of the MCELEMs probably still needs a selectivity estimate of more than zero. I chose instead to clamp to at least what a non-MCELEM word would be estimated as, preserving the property that "word:*" doesn't get an estimate less than plain "word", whether or not the word appears in MCELEM. Per investigation of a gripe from Bill Martin, though I suspect that his example case actually isn't even reaching the erroneous code. Back-patch to 9.1 where this code was introduced. 12 September 2012, 01:23:49 UTC
ef06dca Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches. 10 September 2012, 00:33:03 UTC
1e21450 Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism bug. Investigation shows that some intermittent build failures in ecpg are the result of a gmake bug that was reported quite some time ago: http://savannah.gnu.org/bugs/?30653 Preventing parallel builds of the ecpg subdirectories seems to dodge the bug. Per yesterday's pgsql-hackers discussion, there are some other things in the subdirectory makefiles that seem rather unsafe for parallel builds too, but there's little point in fixing them as long as we have to work around a make bug. Back-patch to 9.1; parallel builds weren't very well supported before that anyway. 09 September 2012, 19:09:11 UTC
ff0b18c Fix PARAM_EXEC assignment mechanism to be safe in the presence of WITH. The planner previously assumed that parameter Vars having the same absolute query level, varno, and varattno could safely be assigned the same runtime PARAM_EXEC slot, even though they might be different Vars appearing in different subqueries. This was (probably) safe before the introduction of CTEs, but the lazy-evalution mechanism used for CTEs means that a CTE can be executed during execution of some other subquery, causing the lifespan of Params at the same syntactic nesting level as the CTE to overlap with use of the same slots inside the CTE. In 9.1 we created additional hazards by using the same parameter-assignment technology for nestloop inner scan parameters, but it was broken before that, as illustrated by the added regression test. To fix, restructure the planner's management of PlannerParamItems so that items having different semantic lifespans are kept rigorously separated. This will probably result in complex queries using more runtime PARAM_EXEC slots than before, but the slots are cheap enough that this hardly matters. Also, stop generating PlannerParamItems containing Params for subquery outputs: all we really need to do is reserve the PARAM_EXEC slot number, and that now only takes incrementing a counter. The planning code is simpler and probably faster than before, as well as being more correct. Per report from Vik Reykja. Back-patch of commit 46c508fbcf98ac334f1e831d21021d731c882fbb into all branches that support WITH. 08 September 2012, 00:38:35 UTC
e40b20a Fix "too many arguments" messages not to index off the end of argv[]. This affects initdb, clusterdb, reindexdb, and vacuumdb in master and 9.2; in earlier branches, only initdb is affected. 06 September 2012, 19:52:15 UTC
18730f8 Fix inappropriate error messages for Hot Standby misconfiguration errors. Give the correct name of the GUC parameter being complained of. Also, emit a more suitable SQLSTATE (INVALID_PARAMETER_VALUE, not the default INTERNAL_ERROR). Gurjeet Singh, errcode adjustment by me 06 September 2012, 01:49:14 UTC
26f4fc0 Fix line end mishandling in pg_upgrade on Windows. pg_upgrade opened the output from pg_dumpall in text mode and wrote the split files in text mode. This caused unwanted eating of intended carriage returns on input and production of spurious carriage returns on output. To avoid this, open all these files in binary mode. On non-Windows platforms, this change has no effect. Backpatch to 9.0. On 9.0 and 9.1, we also switch from redirecting pg_dumpall's output to using pg_dumpall's -f switch, for the same reason. 05 September 2012, 21:49:09 UTC
5ee0f03 Restore SIGFPE handler after initializing PL/Perl. Perl, for some unaccountable reason, believes it's a good idea to reset SIGFPE handling to SIG_IGN. Which wouldn't be a good idea even if it worked; but on some platforms (Linux at least) it doesn't work at all, instead resulting in forced process termination if the signal occurs. Given the lack of other complaints, it seems safe to assume that Perl never actually provokes SIGFPE and so there is no value in the setting anyway. Hence, reset it to our normal handler after initializing Perl. Report, analysis and patch by Andres Freund. 05 September 2012, 20:43:45 UTC
a69b7a1 Indent fix_path_separator() header properly. 04 September 2012, 02:57:21 UTC
d10ddf4 Use correct path separator for Windows builtin commands. pg_upgrade produces a platform-specific script to remove the old directory, but on Windows it has not been making sure that the paths it writes as arguments for rmdir and del use the backslash path separator, which will cause these scripts to fail. The fix is backpatched to Release 9.0. 03 September 2012, 22:11:17 UTC
9739518 Make configure probe for mbstowcs_l as well as wcstombs_l. We previously supposed that any given platform would supply both or neither of these functions, so that one configure test would be sufficient. It now appears that at least on AIX this is not the case ... which is likely an AIX bug, but nonetheless we need to cope with it. So use separate tests. Per bug #6758; thanks to Andrew Hastie for doing the followup testing needed to confirm what was happening. Backpatch to 9.1, where we began using these functions. 31 August 2012, 18:18:08 UTC
6707dd4 Back-patch recent fixes for gistchoose and gistRelocateBuildBuffersOnSplit. This back-ports commits c8ba697a4bdb934f0c51424c654e8db6133ea255 and e5db11c5582b469c04a11f217a0f32c827da5dd7, which fix one definite and one speculative bug in gistchoose, and make the code a lot more intelligible as well. In 9.2 only, this also affects the largely-copied-and-pasted logic in gistRelocateBuildBuffersOnSplit. The impact of the bugs was that the functions might make poor decisions as to which index tree branch to push a new entry down into, resulting in GiST index bloat and poor performance. The fixes rectify these decisions for future insertions, but a REINDEX would be needed to clean up any existing index bloat. Alexander Korotkov, Robert Haas, Tom Lane 31 August 2012, 03:47:54 UTC
f6956eb Document how to prevent PostgreSQL itself from exhausting memory. The existing documentation in Linux Memory Overcommit seemed to assume that PostgreSQL itself could never be the problem, or at least it didn't tell you what to do about it. Per discussion with Craig Ringer and Kevin Grittner. 30 August 2012, 18:23:05 UTC
657face Add missing period to detail message. Per note from Peter Eisentraut. 30 August 2012, 17:27:18 UTC
ed597d0 Back-patch fixes for some issues in our Windows socket code into 9.1. This is a backport of commit b85427f2276d02756b558c0024949305ea65aca5. Per discussion of bug #4958. Some of these fixes probably need to be back-patched further, but I'm just doing this much for now. 27 August 2012, 19:00:08 UTC
180ce0a Fix issues with checks for unsupported transaction states in Hot Standby. The GUC check hooks for transaction_read_only and transaction_isolation tried to check RecoveryInProgress(), so as to disallow setting read/write mode or serializable isolation level (respectively) in hot standby sessions. However, GUC check hooks can be called in many situations where we're not connected to shared memory at all, resulting in a crash in RecoveryInProgress(). Among other cases, this results in EXEC_BACKEND builds crashing during child process start if default_transaction_isolation is serializable, as reported by Heikki Linnakangas. Protect those calls by silently allowing any setting when not inside a transaction; which is okay anyway since these GUCs are always reset at start of transaction. Also, add a check to GetSerializableTransactionSnapshot() to complain if we are in hot standby. We need that check despite the one in check_XactIsoLevel() because default_transaction_isolation could be serializable. We don't want to complain any sooner than this in such cases, since that would prevent running transactions at all in such a state; but a transaction can be run, if SET TRANSACTION ISOLATION is done before setting a snapshot. Per report some months ago from Robert Haas. Back-patch to 9.1, since these problems were introduced by the SSI patch. Kevin Grittner and Tom Lane, with ideas from Heikki Linnakangas 24 August 2012, 17:09:17 UTC
ff122d3 Fix cascading privilege revoke to notice when privileges are still held. If we revoke a grant option from some role X, but X still holds the option via another grant, we should not recursively revoke the privilege from role(s) Y that X had granted it to. This was supposedly fixed as one aspect of commit 4b2dafcc0b1a579ef5daaa2728223006d1ff98e9, but I must not have tested it, because in fact that code never worked: it forgot to shift the grant-option bits back over when masking the bits being revoked. Per bug #6728 from Daniel German. Back-patch to all active branches, since this has been wrong since 8.0. 23 August 2012, 21:25:23 UTC
874d97c Fix bugs in contrib/pg_trgm's LIKE pattern analysis code. Extraction of trigrams did not process LIKE escape sequences properly, leading to possible misidentification of trigrams near escapes, resulting in incorrect index search results. Fujii Masao 20 August 2012, 17:25:03 UTC
7665e82 Fix rescan logic in nodeCtescan. The previous coding essentially assumed that nodes would be rescanned in the same order they were initialized in; or at least that the "leader" of a group of CTEscans would be rescanned before any others were required to execute. Unfortunately, that isn't even a little bit true. It's possible to devise queries in which the leader isn't rescanned until other CTEscans on the same CTE have run to completion, or even in which the leader never gets a rescan call at all. The fix makes the leader specially responsible only for initial creation and final destruction of the tuplestore; rescan resets are now a symmetrically shared responsibility. This means that we might reset the tuplestore multiple times when restarting a plan subtree containing multiple CTEscans; but resetting an already-empty tuplestore is cheap enough that that doesn't seem like a problem. Per report from Adam Mackler; the new regression test cases are based on his example query. Back-patch to 8.4 where CTE scans were introduced. 15 August 2012, 23:01:29 UTC
9e03518 Disallow extensions from owning the schema they are assigned to. This situation creates a dependency loop that confuses pg_dump and probably other things. Moreover, since the mental model is that the extension "contains" schemas it owns, but "is contained in" its extschema (even though neither is strictly true), having both true at once is confusing for people too. So prevent the situation from being set up. Reported and patched by Thom Brown. Back-patch to 9.1 where extensions were added. 15 August 2012, 15:27:06 UTC
04e96bc Stamp 9.1.5. 14 August 2012, 22:41:04 UTC
18ee575 Update release notes for 9.1.5, 9.0.9, 8.4.13, 8.3.20. 14 August 2012, 22:34:07 UTC
e76e252 Prevent access to external files/URLs via contrib/xml2's xslt_process(). libxslt offers the ability to read and write both files and URLs through stylesheet commands, thus allowing unprivileged database users to both read and write data with the privileges of the database server. Disable that through proper use of libxslt's security options. Also, remove xslt_process()'s ability to fetch documents and stylesheets from external files/URLs. While this was a documented "feature", it was long regarded as a terrible idea. The fix for CVE-2012-3489 broke that capability, and rather than expend effort on trying to fix it, we're just going to summarily remove it. While the ability to write as well as read makes this security hole considerably worse than CVE-2012-3489, the problem is mitigated by the fact that xslt_process() is not available unless contrib/xml2 is installed, and the longstanding warnings about security risks from that should have discouraged prudent DBAs from installing it in security-exposed databases. Reported and fixed by Peter Eisentraut. Security: CVE-2012-3488 14 August 2012, 22:32:03 UTC
0df2da9 Prevent access to external files/URLs via XML entity references. xml_parse() would attempt to fetch external files or URLs as needed to resolve DTD and entity references in an XML value, thus allowing unprivileged database users to attempt to fetch data with the privileges of the database server. While the external data wouldn't get returned directly to the user, portions of it could be exposed in error messages if the data didn't parse as valid XML; and in any case the mere ability to check existence of a file might be useful to an attacker. The ideal solution to this would still allow fetching of references that are listed in the host system's XML catalogs, so that documents can be validated according to installed DTDs. However, doing that with the available libxml2 APIs appears complex and error-prone, so we're not going to risk it in a security patch that necessarily hasn't gotten wide review. So this patch merely shuts off all access, causing any external fetch to silently expand to an empty string. A future patch may improve this. In HEAD and 9.2, also suppress warnings about undefined entities, which would otherwise occur as a result of not loading referenced DTDs. Previous branches don't show such warnings anyway, due to different error handling arrangements. Credit to Noah Misch for first reporting the problem, and for much work towards a solution, though this simplistic approach was not his preference. Also thanks to Daniel Veillard for consultation. Security: CVE-2012-3489 14 August 2012, 22:32:02 UTC
b5987c4 Translation updates 14 August 2012, 20:34:12 UTC
back to top