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
ad670a5 Tom Lane 02 December 2013, 21:04:20 UTC Stamp 9.0.15. 02 December 2013, 21:04:20 UTC
81fb8ff Tom Lane 02 December 2013, 20:54:08 UTC Update release notes for 9.3.2, 9.2.6, 9.1.11, 9.0.15, 8.4.19. 02 December 2013, 20:54:08 UTC
3d974e3 Alvaro Herrera 02 December 2013, 16:28:10 UTC Fix incomplete backpatch of pg_multixact truncation changes to <= 9.2 The backpatch of a95335b544d9c8377e9dc7a399d8e9a155895f82 to 9.2, 9.1 and 9.0 was incomplete, missing changes to xlog.c, primarily the call to TrimMultiXact(). Testing presumably didn't show a problem without these changes because TrimMultiXact() performs defense-in-depth work, which is not strictly necessary. It also missed moving StartupMultiXact() which would have been problematic if a restartpoing happened in exactly the wrong moment, causing a transient error. Andres Freund 02 December 2013, 16:28:10 UTC
8269e40 Peter Eisentraut 02 December 2013, 05:05:18 UTC Translation updates 02 December 2013, 05:05:18 UTC
4743045 Tom Lane 01 December 2013, 19:11:44 UTC Update time zone data files to tzdata release 2013h. DST law changes in Argentina, Brazil, Jordan, Libya, Liechtenstein, Morocco, Palestine. New timezone abbreviations WIB, WIT, WITA for Indonesia. 01 December 2013, 19:12:12 UTC
126453d Tom Lane 01 December 2013, 19:09:31 UTC Back-patch src/timezone/known_abbrevs.txt into all active branches. Needed so that timezone data update patches can be cherry-picked into older branches conveniently. 01 December 2013, 19:09:53 UTC
52898e0 Kevin Grittner 30 November 2013, 18:07:05 UTC Fix pg_dumpall to work for databases flagged as read-only. pg_dumpall's charter is to be able to recreate a database cluster's contents in a virgin installation, but it was failing to honor that contract if the cluster had any ALTER DATABASE SET default_transaction_read_only settings. By including a SET command for the connection for each connection opened by pg_dumpall output, errors are avoided and the source cluster is successfully recreated. There was discussion of whether to also set this for the connection applying pg_dump output, but it was felt that it was both less appropriate in that context, and far easier to work around. Backpatch to all supported branches. 30 November 2013, 18:07:05 UTC
a74f50a Tom Lane 30 November 2013, 16:12:16 UTC Prevent possible compiler warnings. Back-patch commit a3e8486dffc413506b14eae9dc5d423f6ae8324a into the 9.0 branch. This is the only warning I'm seeing in the live branches with gcc 4.4.7 (other than the known "unused variable 'yyg'" flex lossage), which makes it just annoying enough to want to clean up. 30 November 2013, 16:12:16 UTC
6d0b8cd Alvaro Herrera 29 November 2013, 14:26:41 UTC Truncate pg_multixact/'s contents during crash recovery Commit 9dc842f08 of 8.2 era prevented MultiXact truncation during crash recovery, because there was no guarantee that enough state had been setup, and because it wasn't deemed to be a good idea to remove data during crash recovery anyway. Since then, due to Hot-Standby, streaming replication and PITR, the amount of time a cluster can spend doing crash recovery has increased significantly, to the point that a cluster may even never come out of it. This has made not truncating the content of pg_multixact/ not defensible anymore. To fix, take care to setup enough state for multixact truncation before crash recovery starts (easy since checkpoints contain the required information), and move the current end-of-recovery actions to a new TrimMultiXact() function, analogous to TrimCLOG(). At some later point, this should probably done similarly to the way clog.c is doing it, which is to just WAL log truncations, but we can't do that for the back branches. Back-patch to 9.0. 8.4 also has the problem, but since there's no hot standby there, it's much less pressing. In 9.2 and earlier, this patch is simpler than in newer branches, because multixact access during recovery isn't required. Add appropriate checks to make sure that's not happening. Andres Freund 30 November 2013, 01:02:15 UTC
4ab4e5c Tom Lane 29 November 2013, 23:34:22 UTC Fix assorted issues in pg_ctl's pgwin32_CommandLine(). Ensure that the invocation command for postgres or pg_ctl runservice double-quotes the executable's pathname; failure to do this leads to trouble when the path contains spaces. Also, ensure that the path ends in ".exe" in both cases and uses backslashes rather than slashes as directory separators. The latter issue is reported to confuse some third-party tools such as Symantec Backup Exec. Also, rewrite the function to avoid buffer overrun issues by using a PQExpBuffer instead of a fixed-size static buffer. Combinations of very long executable pathnames and very long data directory pathnames could have caused trouble before, for example. Back-patch to all active branches, since this code has been like this for a long while. Naoya Anzai and Tom Lane, reviewed by Rajeev Rastogi 29 November 2013, 23:34:22 UTC
ba63799 Heikki Linnakangas 27 November 2013, 11:10:16 UTC Don't update relfrozenxid if any pages were skipped. Vacuum recognizes that it can update relfrozenxid by checking whether it has processed all pages of a relation. Unfortunately it performed that check after truncating the dead pages at the end of the relation, and used the new number of pages to decide whether all pages have been scanned. If the new number of pages happened to be smaller or equal to the number of pages scanned, it incorrectly decided that all pages were scanned. This can lead to relfrozenxid being updated, even though some pages were skipped that still contain old XIDs. That can lead to data loss due to xid wraparounds with some rows suddenly missing. This likely has escaped notice so far because it takes a large number (~2^31) of xids being used to see the effect, while a full-table vacuum before that would fix the issue. The incorrect logic was introduced by commit b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8. Backpatch this fix down to 8.4, like that commit. Andres Freund, with some modifications by me. 27 November 2013, 11:43:18 UTC
ddd8416 Michael Meskes 26 November 2013, 16:16:39 UTC ECPG: Fix offset to NULL/size indicator array. Patch by Boszormenyi Zoltan <zb@cybertec.at> 26 November 2013, 16:31:45 UTC
7bee2e3 Michael Meskes 26 November 2013, 16:12:39 UTC ECPG: Make the preprocessor emit ';' if the variable type for a list of variables is varchar. This fixes this test case: int main(void) { exec sql begin declare section; varchar a[50], b[50]; exec sql end declare section; return 0; } Since varchars are internally turned into custom structs and the type name is emitted for these variable declarations, the preprocessed code previously had: struct varchar_1 { ... } a _,_ struct varchar_2 { ... } b ; The comma in the generated C file was a syntax error. There are no regression test changes since it's not exercised. Patch by Boszormenyi Zoltan <zb@cybertec.at> Conflicts: src/interfaces/ecpg/preproc/ecpg.trailer 26 November 2013, 16:31:39 UTC
cd5316f Tom Lane 24 November 2013, 03:45:46 UTC Defend against bad trigger definitions in contrib/lo's lo_manage() trigger. This function formerly crashed if called as a statement-level trigger, or if a column-name argument wasn't given. In passing, add the trigger name to all error messages from the function. (None of them are expected cases, so this shouldn't pose any compatibility risk.) Marc Cousin, reviewed by Sawada Masahiko 24 November 2013, 03:46:15 UTC
747dd97 Tom Lane 24 November 2013, 01:04:10 UTC Fix array slicing of int2vector and oidvector values. The previous coding labeled expressions such as pg_index.indkey[1:3] as being of int2vector type; which is not right because the subscript bounds of such a result don't, in general, satisfy the restrictions of int2vector. To fix, implicitly promote the result of slicing int2vector to int2[], or oidvector to oid[]. This is similar to what we've done with domains over arrays, which is a good analogy because these types are very much like restricted domains of the corresponding regular-array types. A side-effect is that we now also forbid array-element updates on such columns, eg while "update pg_index set indkey[4] = 42" would have worked before if you were superuser (and corrupted your catalogs irretrievably, no doubt) it's now disallowed. This seems like a good thing since, again, some choices of subscripting would've led to results not satisfying the restrictions of int2vector. The case of an array-slice update was rejected before, though with a different error message than you get now. We could make these cases work in future if we added a cast from int2[] to int2vector (with a cast function checking the subscript restrictions) but it seems unlikely that there's any value in that. Per report from Ronan Dunklau. Back-patch to all supported branches because of the crash risks involved. 24 November 2013, 01:04:10 UTC
ec6a6a2 Tom Lane 23 November 2013, 23:24:26 UTC Ensure _dosmaperr() actually sets errno correctly. If logging is enabled, either ereport() or fprintf() might stomp on errno internally, causing this function to return the wrong result. That might only end in a misleading error report, but in any code that's examining errno to decide what to do next, the consequences could be far graver. This has been broken since the very first version of this file in 2006 ... it's a bit astonishing that we didn't identify this long ago. Reported by Amit Kapila, though this isn't his proposed fix. 23 November 2013, 23:24:54 UTC
4403229 Peter Eisentraut 23 November 2013, 12:25:37 UTC Avoid potential buffer overflow crash A pointer to a C string was treated as a pointer to a "name" datum and passed to SPI_execute_plan(). This pointer would then end up being passed through datumCopy(), which would try to copy the entire 64 bytes of name data, thus running past the end of the C string. Fix by converting the string to a proper name structure. Found by LLVM AddressSanitizer. 23 November 2013, 12:31:32 UTC
612f953 Tom Lane 22 November 2013, 19:37:35 UTC Flatten join alias Vars before pulling up targetlist items from a subquery. pullup_replace_vars()'s decisions about whether a pulled-up replacement expression needs to be wrapped in a PlaceHolderVar depend on the assumption that what looks like a Var behaves like a Var. However, if the Var is a join alias reference, later flattening of join aliases might replace the Var with something that's not a Var at all, and should have been wrapped. To fix, do a forcible pass of flatten_join_alias_vars() on the subquery targetlist before we start to copy items out of it. We'll re-run that processing on the pulled-up expressions later, but that's harmless. Per report from Ken Tanzer; the added regression test case is based on his example. This bug has been there since the PlaceHolderVar mechanism was invented, but has escaped detection because the circumstances that trigger it are fairly narrow. You need a flattenable query underneath an outer join, which contains another flattenable query inside a join of its own, with a dangerous expression (a constant or something else non-strict) in that one's targetlist. Having seen this, I'm wondering if it wouldn't be prudent to do all alias-variable flattening earlier, perhaps even in the rewriter. But that would probably not be a back-patchable change. 22 November 2013, 19:37:35 UTC
b4f697f Heikki Linnakangas 22 November 2013, 12:38:59 UTC Fix Hot-Standby initialization of clog and subtrans. These bugs can cause data loss on standbys started with hot_standby=on at the moment they start to accept read only queries, by marking committed transactions as uncommited. The likelihood of such corruptions is small unless the primary has a high transaction rate. 5a031a5556ff83b8a9646892715d7fef415b83c3 fixed bugs in HS's startup logic by maintaining less state until at least STANDBY_SNAPSHOT_PENDING state was reached, missing the fact that both clog and subtrans are written to before that. This only failed to fail in common cases because the usage of ExtendCLOG in procarray.c was superflous since clog extensions are actually WAL logged. f44eedc3f0f347a856eea8590730769125964597/I then tried to fix the missing extensions of pg_subtrans due to the former commit's changes - which are not WAL logged - by performing the extensions when switching to a state > STANDBY_INITIALIZED and not performing xid assignments before that - again missing the fact that ExtendCLOG is unneccessary - but screwed up twice: Once because latestObservedXid wasn't updated anymore in that state due to the earlier commit and once by having an off-by-one error in the loop performing extensions. This means that whenever a CLOG_XACTS_PER_PAGE (32768 with default settings) boundary was crossed between the start of the checkpoint recovery started from and the first xl_running_xact record old transactions commit bits in pg_clog could be overwritten if they started and committed in that window. Fix this mess by not performing ExtendCLOG() in HS at all anymore since it's unneeded and evidently dangerous and by performing subtrans extensions even before reaching STANDBY_SNAPSHOT_PENDING. Analysis and patch by Andres Freund. Reported by Christophe Pettus. Backpatch down to 9.0, like the previous commit that caused this. 22 November 2013, 12:49:07 UTC
32b3284 Tom Lane 15 November 2013, 23:34:14 UTC Fix incorrect loop counts in tidbitmap.c. A couple of places that should have been iterating over WORDS_PER_CHUNK words were iterating over WORDS_PER_PAGE words instead. This thinko accidentally failed to fail, because (at least on common architectures with default BLCKSZ) WORDS_PER_CHUNK is a bit less than WORDS_PER_PAGE, and the extra words being looked at were always zero so nothing happened. Still, it's a bug waiting to happen if anybody ever fools with the parameters affecting TIDBitmap sizes, and it's a small waste of cycles too. So back-patch to all active branches. Etsuro Fujita 15 November 2013, 23:34:34 UTC
1821ef1 Tom Lane 13 November 2013, 18:26:33 UTC Clarify CREATE FUNCTION documentation about handling of typmods. The previous text was a bit misleading, as well as unnecessarily vague about what information would be discarded. Per gripe from Craig Skinner. 13 November 2013, 18:26:51 UTC
0b336fb Magnus Hagander 12 November 2013, 11:53:32 UTC Fix doc links in README file to work with new website layout Per report from Colin 't Hart 12 November 2013, 11:54:43 UTC
4b099e1 Heikki Linnakangas 08 November 2013, 20:21:42 UTC Fix race condition in GIN posting tree page deletion. If a page is deleted, and reused for something else, just as a search is following a rightlink to it from its left sibling, the search would continue scanning whatever the new contents of the page are. That could lead to incorrect query results, or even something more curious if the page is reused for a different kind of a page. To fix, modify the search algorithm to lock the next page before releasing the previous one, and refrain from deleting pages from the leftmost branch of the tree. Add a new Concurrency section to the README, explaining why this works. There is a lot more one could say about concurrency in GIN, but that's for another patch. Backpatch to all supported versions. 08 November 2013, 20:23:16 UTC
987f05e Tom Lane 08 November 2013, 16:37:12 UTC Make contain_volatile_functions/contain_mutable_functions look into SubLinks. This change prevents us from doing inappropriate subquery flattening in cases such as dangerous functions hidden inside a sub-SELECT in the targetlist of another sub-SELECT. That could result in unexpected behavior due to multiple evaluations of a volatile function, as in a recent complaint from Etienne Dube. It's been questionable from the very beginning whether these functions should look into subqueries (as noted in their comments), and this case seems to provide proof that they should. Because the new code only descends into SubLinks, not SubPlans or InitPlans, the change only affects the planner's behavior during prepjointree processing and not later on --- for example, you can still get it to use a volatile function in an indexqual if you wrap the function in (SELECT ...). That's a historical behavior, for sure, but it's reasonable given that the executor's evaluation rules for subplans don't depend on whether there are volatile functions inside them. In any case, we need to constrain the behavioral change as narrowly as we can to make this reasonable to back-patch. 08 November 2013, 16:37:12 UTC
8103f49 Tom Lane 07 November 2013, 21:33:34 UTC Be more robust when strerror() doesn't give a useful result. Back-patch commits 8e68816cc2567642c6fcca4eaac66c25e0ae5ced and 8dace66e0735ca39b779922d02c24ea2686e6521 into the stable branches. Buildfarm testing revealed no great portability surprises, and it seems useful to have this robustness improvement in all branches. 07 November 2013, 21:33:34 UTC
352ab59 Tom Lane 06 November 2013, 18:32:30 UTC Prevent creating window functions with default arguments. Insertion of default arguments doesn't work for window functions, which is likely to cause a crash at runtime if the implementation code doesn't check the number of actual arguments carefully. It doesn't seem worth working harder than this for pre-9.2 branches. 06 November 2013, 18:32:30 UTC
3dd1310 Tom Lane 06 November 2013, 02:58:23 UTC Improve the error message given for modifying a window with frame clause. For rather inscrutable reasons, SQL:2008 disallows copying-and-modifying a window definition that has any explicit framing clause. The error message we gave for this only made sense if the referencing window definition itself contains an explicit framing clause, which it might well not. Moreover, in the context of an OVER clause it's not exactly obvious that "OVER (windowname)" implies copy-and-modify while "OVER windowname" does not. This has led to multiple complaints, eg bug #5199 from Iliya Krapchatov. Change to a hopefully more intelligible error message, and in the case where we have just "OVER (windowname)", add a HINT suggesting that omitting the parentheses will fix it. Also improve the related documentation. Back-patch to all supported branches. 06 November 2013, 02:58:23 UTC
da174fb Michael Meskes 03 November 2013, 14:37:34 UTC Changed test case slightly so it doesn't have an unused typedef. 03 November 2013, 15:18:10 UTC
0c8462f Tom Lane 01 November 2013, 20:10:03 UTC Ensure all files created for a single BufFile have the same resource owner. Callers expect that they only have to set the right resource owner when creating a BufFile, not during subsequent operations on it. While we could insist this be fixed at the caller level, it seems more sensible for the BufFile to take care of it. Without this, some temp files belonging to a BufFile can go away too soon, eg at the end of a subtransaction, leading to errors or crashes. Reported and fixed by Andres Freund. Back-patch to all active branches. 01 November 2013, 20:10:03 UTC
d81cd04 Tom Lane 01 November 2013, 16:13:33 UTC Fix some odd behaviors when using a SQL-style simple GMT offset timezone. Formerly, when using a SQL-spec timezone setting with a fixed GMT offset (called a "brute force" timezone in the code), the session_timezone variable was not updated to match the nominal timezone; rather, all code was expected to ignore session_timezone if HasCTZSet was true. This is of course obviously fragile, though a search of the code finds only timeofday() failing to honor the rule. A bigger problem was that DetermineTimeZoneOffset() supposed that if its pg_tz parameter was pointer-equal to session_timezone, then HasCTZSet should override the parameter. This would cause datetime input containing an explicit zone name to be treated as referencing the brute-force zone instead, if the zone name happened to match the session timezone that had prevailed before installing the brute-force zone setting (as reported in bug #8572). The same malady could affect AT TIME ZONE operators. To fix, set up session_timezone so that it matches the brute-force zone specification, which we can do using the POSIX timezone definition syntax "<abbrev>offset", and get rid of the bogus lookaside check in DetermineTimeZoneOffset(). Aside from fixing the erroneous behavior in datetime parsing and AT TIME ZONE, this will cause the timeofday() function to print its result in the user-requested time zone rather than some previously-set zone. It might also affect results in third-party extensions, if there are any that make use of session_timezone without considering HasCTZSet, but in all cases the new behavior should be saner than before. Back-patch to all supported branches. 01 November 2013, 16:13:33 UTC
aad45bd Tom Lane 29 October 2013, 00:49:38 UTC Prevent using strncpy with src == dest in TupleDescInitEntry. The C and POSIX standards state that strncpy's behavior is undefined when source and destination areas overlap. While it remains dubious whether any implementations really misbehave when the pointers are exactly equal, some platforms are now starting to force the issue by complaining when an undefined call occurs. (In particular OS X 10.9 has been seen to dump core here, though the exact set of circumstances needed to trigger that remain elusive. Similar behavior can be expected to be optional on Linux and other platforms in the near future.) So tweak the code to explicitly do nothing when nothing need be done. Back-patch to all active branches. In HEAD, this also lets us get rid of an exception in valgrind.supp. Per discussion of a report from Matthias Schmitt. 29 October 2013, 00:49:38 UTC
42ef7c8 Peter Eisentraut 03 July 2013, 00:32:09 UTC doc: Remove i18ngurus.com link The web site is dead, and the Wayback Machine shows that it didn't have much useful content before. 21 October 2013, 10:23:56 UTC
ca49679 Bruce Momjian 09 October 2013, 12:44:52 UTC doc: fix typo in release notes Backpatch through 8.4 Per suggestion by Amit Langote 09 October 2013, 12:44:52 UTC
a65e6c8 Peter Eisentraut 08 October 2013, 03:12:23 UTC Stamp 9.0.14. 08 October 2013, 03:12:23 UTC
b7854a0 Bruce Momjian 08 October 2013, 01:35:01 UTC docs: update release notes for 8.4.18, 9.0.14, 9.1.10, 9.2.5, 9.3.1 08 October 2013, 01:35:01 UTC
676f3d2 Peter Eisentraut 07 October 2013, 20:12:32 UTC Translation updates 07 October 2013, 20:12:32 UTC
aeb366f Peter Eisentraut 03 October 2013, 01:33:26 UTC doc: Correct psycopg URL 03 October 2013, 01:34:40 UTC
c5c87f0 Heikki Linnakangas 30 September 2013, 08:29:09 UTC Fix snapshot leak if lo_open called on non-existent object. lo_open registers the currently active snapshot, and checks if the large object exists after that. Normally, snapshots registered by lo_open are unregistered at end of transaction when the lo descriptor is closed, but if we error out before the lo descriptor is added to the list of open descriptors, it is leaked. Fix by moving the snapshot registration to after checking if the large object exists. Reported by Pavel Stehule. Backpatch to 8.4. The snapshot registration system was introduced in 8.4, so prior versions are not affected (and not supported, anyway). 30 September 2013, 09:58:51 UTC
ca4ac3f Heikki Linnakangas 26 September 2013, 08:24:40 UTC Fix spurious warning after vacuuming a page on a table with no indexes. There is a rare race condition, when a transaction that inserted a tuple aborts while vacuum is processing the page containing the inserted tuple. Vacuum prunes the page first, which normally removes any dead tuples, but if the inserting transaction aborts right after that, the loop after pruning will see a dead tuple and remove it instead. That's OK, but if the page is on a table with no indexes, and the page becomes completely empty after removing the dead tuple (or tuples) on it, it will be immediately marked as all-visible. That's OK, but the sanity check in vacuum would throw a warning because it thinks that the page contains dead tuples and was nevertheless marked as all-visible, even though it just vacuumed away the dead tuples and so it doesn't actually contain any. Spotted this while reading the code. It's difficult to hit the race condition otherwise, but can be done by putting a breakpoint after the heap_page_prune() call. Backpatch all the way to 8.4, where this code first appeared. 26 September 2013, 08:39:13 UTC
5d16299 Alvaro Herrera 24 September 2013, 21:19:14 UTC Fix pgindent comment breakage 24 September 2013, 21:21:50 UTC
1ba5fe8 Stephen Frost 23 September 2013, 12:33:41 UTC Fix SSL deadlock risk in libpq In libpq, we set up and pass to OpenSSL callback routines to handle locking. When we run out of SSL connections, we try to clean things up by de-registering the hooks. Unfortunately, we had a few calls into the OpenSSL library after these hooks were de-registered during SSL cleanup which lead to deadlocking. This moves the thread callback cleanup to be after all SSL-cleanup related OpenSSL library calls. I've been unable to reproduce the deadlock with this fix. In passing, also move the close_SSL call to be after unlocking our ssl_config mutex when in a failure state. While it looks pretty unlikely to be an issue, it could have resulted in deadlocks if we ended up in this code path due to something other than SSL_new failing. Thanks to Heikki for pointing this out. Back-patch to all supported versions; note that the close_SSL issue only goes back to 9.0, so that hunk isn't included in the 8.4 patch. Initially found and reported by Vesa-Matti J Kari; many thanks to both Heikki and Andres for their help running down the specific issue and reviewing the patch. 23 September 2013, 12:43:15 UTC
9553d0f Noah Misch 12 September 2013, 00:10:15 UTC Ignore interrupts during quickdie(). Once the administrator has called for an immediate shutdown or a backend crash has triggered a reinitialization, no mere SIGINT or SIGTERM should change that course. Such derailment remains possible when the signal arrives before quickdie() blocks signals. That being a narrow race affecting most PostgreSQL signal handlers in some way, leave it for another patch. Back-patch this to all supported versions. 12 September 2013, 00:14:41 UTC
994f68d Michael Meskes 08 September 2013, 10:59:43 UTC Return error if allocation of new element was not possible. Found by Coverity. 08 September 2013, 11:13:32 UTC
3f092db Michael Meskes 08 September 2013, 10:49:54 UTC Close file to no leak file descriptor memory. Found by Coverity. 08 September 2013, 11:13:32 UTC
fde440e Tom Lane 03 September 2013, 22:32:32 UTC Don't fail for bad GUCs in CREATE FUNCTION with check_function_bodies off. The previous coding attempted to activate all the GUC settings specified in SET clauses, so that the function validator could operate in the GUC environment expected by the function body. However, this is problematic when restoring a dump, since the SET clauses might refer to database objects that don't exist yet. We already have the parameter check_function_bodies that's meant to prevent forward references in function definitions from breaking dumps, so let's change CREATE FUNCTION to not install the SET values if check_function_bodies is off. Authors of function validators were already advised not to make any "context sensitive" checks when check_function_bodies is off, if indeed they're checking anything at all in that mode. But extend the documentation to point out the GUC issue in particular. (Note that we still check the SET clauses to some extent; the behavior with !check_function_bodies is now approximately equivalent to what ALTER DATABASE/ROLE have been doing for awhile with context-dependent GUCs.) This problem can be demonstrated in all active branches, so back-patch all the way. 03 September 2013, 22:32:32 UTC
cec83f6 Tom Lane 02 September 2013, 19:06:21 UTC Update time zone data files to tzdata release 2013d. DST law changes in Israel, Morocco, Palestine, Paraguay. Historical corrections for Macquarie Island. 02 September 2013, 19:06:42 UTC
d1f638b Andrew Dunstan 02 September 2013, 18:35:26 UTC Fix relfrozenxid query in docs to include TOAST tables. The original query ignored TOAST tables which could result in tables needing a vacuum not being reported. Backpatch to all live branches. 02 September 2013, 18:35:26 UTC
fb5941d Tom Lane 23 August 2013, 21:31:06 UTC In locate_grouping_columns(), don't expect an exact match of Var typmods. It's possible that inlining of SQL functions (or perhaps other changes?) has exposed typmod information not known at parse time. In such cases, Vars generated by query_planner might have valid typmod values while the original grouping columns only have typmod -1. This isn't a semantic problem since the behavior of grouping only depends on type not typmod, but it breaks locate_grouping_columns' use of tlist_member to locate the matching entry in query_planner's result tlist. We can fix this without an excessive amount of new code or complexity by relying on the fact that locate_grouping_columns only gets called when make_subplanTargetList has set need_tlist_eval == false, and that can only happen if all the grouping columns are simple Vars. Therefore we only need to search the sub_tlist for a matching Var, and we can reasonably define a "match" as being a match of the Var identity fields varno/varattno/varlevelsup. The code still Asserts that vartype matches, but ignores vartypmod. Per bug #8393 from Evan Martin. The added regression test case is basically the same as his example. This has been broken for a very long time, so back-patch to all supported branches. 23 August 2013, 21:31:06 UTC
e9e387a Tom Lane 21 August 2013, 22:31:51 UTC Disable -faggressive-loop-optimizations in gcc 4.8+ for pre-9.2 branches. With this optimization flag enabled, recent versions of gcc can generate incorrect code that assumes variable-length arrays (such as oidvector) are actually fixed-length because they're embedded in some larger struct. The known instance of this problem was fixed in 9.2 and up by commit 8137f2c32322c624e0431fac1621e8e9315202f9 and followon work, which hides actually-variable-length catalog fields from the compiler altogether. And we plan to gradually convert variable-length fields to official "flexible array member" notation over time, which should prevent this type of bug from reappearing as gcc gets smarter. We're not going to try to back-port those changes into older branches, though, so apply this band-aid instead. Andres Freund 21 August 2013, 22:31:51 UTC
8e0b7d2 Peter Eisentraut 18 August 2013, 01:46:32 UTC libpq: Report strerror on pthread_mutex_lock() failure 18 August 2013, 01:55:15 UTC
32b5a96 Tom Lane 03 August 2013, 16:40:01 UTC Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be. 03 August 2013, 16:40:49 UTC
646b121 Alvaro Herrera 02 August 2013, 18:34:56 UTC Fix old visibility bug in HeapTupleSatisfiesDirty If a tuple is locked but not updated by a concurrent transaction, HeapTupleSatisfiesDirty would return that transaction's Xid in xmax, causing callers to wait on it, when it is not necessary (in fact, if the other transaction had used a multixact instead of a plain Xid to mark the tuple, HeapTupleSatisfiesDirty would have behave differently and *not* returned the Xmax). This bug was introduced in commit 3f7fbf85dc5b42, dated December 1998, so it's almost 15 years old now. However, it's hard to see this misbehave, because before we had NOWAIT the only consequence of this is that transactions would wait for slightly more time than necessary; so it's not surprising that this hasn't been reported yet. Craig Ringer and Andres Freund 02 August 2013, 21:07:20 UTC
f019c02 Stephen Frost 01 August 2013, 19:42:07 UTC Improve handling of pthread_mutex_lock error case We should really be reporting a useful error along with returning a valid return code if pthread_mutex_lock() throws an error for some reason. Add that and back-patch to 9.0 as the prior patch. Pointed out by Alvaro Herrera 01 August 2013, 19:43:49 UTC
f310163 Stephen Frost 01 August 2013, 05:15:45 UTC Add locking around SSL_context usage in libpq I've been working with Nick Phillips on an issue he ran into when trying to use threads with SSL client certificates. As it turns out, the call in initialize_SSL() to SSL_CTX_use_certificate_chain_file() will modify our SSL_context without any protection from other threads also calling that function or being at some other point and trying to read from SSL_context. To protect against this, I've written up the attached (based on an initial patch from Nick and much subsequent discussion) which puts locks around SSL_CTX_use_certificate_chain_file() and all of the other users of SSL_context which weren't already protected. Nick Phillips, much reworked by Stephen Frost Back-patch to 9.0 where we started loading the cert directly instead of using a callback. 01 August 2013, 05:24:05 UTC
5a27056 Tom Lane 31 July 2013, 15:31:37 UTC Fix regexp_matches() handling of zero-length matches. We'd find the same match twice if it was of zero length and not immediately adjacent to the previous match. replace_text_regexp() got similar cases right, so adjust this search logic to match that. Note that even though the regexp_split_to_xxx() functions share this code, they did not display equivalent misbehavior, because the second match would be considered degenerate and ignored. Jeevan Chalke, with some cosmetic changes by me. 31 July 2013, 15:31:37 UTC
6c1fec9 Noah Misch 30 July 2013, 22:36:52 UTC Restore REINDEX constraint validation. Refactoring as part of commit 8ceb24568054232696dddc1166a8563bc78c900a had the unintended effect of making REINDEX TABLE and REINDEX DATABASE no longer validate constraints enforced by the indexes in question; REINDEX INDEX still did so. Indexes marked invalid remained so, and constraint violations arising from data corruption went undetected. Back-patch to 9.0, like the causative commit. 31 July 2013, 00:00:31 UTC
3587f78 Tom Lane 29 July 2013, 14:42:51 UTC Fix contrib/cube and contrib/seg to build with bison 3.0. These modules used the YYPARSE_PARAM macro, which has been deprecated by the bison folk since 1.875, and which they finally removed in 3.0. Adjust the code to use the replacement facility, %parse-param, which is a much better solution anyway since it allows specification of the type of the extra parser parameter. We can thus get rid of a lot of unsightly casting. Back-patch to all active branches, since somebody might try to build a back branch with up-to-date tools. 29 July 2013, 14:42:51 UTC
8e992b0 Tom Lane 24 July 2013, 04:44:09 UTC Fix booltestsel() for case where we have NULL stats but not MCV stats. In a boolean column that contains mostly nulls, ANALYZE might not find enough non-null values to populate the most-common-values stats, but it would still create a pg_statistic entry with stanullfrac set. The logic in booltestsel() for this situation did the wrong thing for "col IS NOT TRUE" and "col IS NOT FALSE" tests, forgetting that null values would satisfy these tests (so that the true selectivity would be close to one, not close to zero). Per bug #8274. Fix by Andrew Gierth, some comment-smithing by me. 24 July 2013, 04:44:59 UTC
f6a6d20 Alvaro Herrera 23 July 2013, 21:38:31 UTC Check for NULL result from strdup Per Coverity Scan 23 July 2013, 21:38:31 UTC
0483608 Tom Lane 23 July 2013, 20:23:16 UTC Change post-rewriter representation of dropped columns in joinaliasvars. It's possible to drop a column from an input table of a JOIN clause in a view, if that column is nowhere actually referenced in the view. But it will still be there in the JOIN clause's joinaliasvars list. We used to replace such entries with NULL Const nodes, which is handy for generation of RowExpr expansion of a whole-row reference to the view. The trouble with that is that it can't be distinguished from the situation after subquery pull-up of a constant subquery output expression below the JOIN. Instead, replace such joinaliasvars with null pointers (empty expression trees), which can't be confused with pulled-up expressions. expandRTE() still emits the old convention, though, for convenience of RowExpr generation and to reduce the risk of breaking extension code. In HEAD and 9.3, this patch also fixes a problem with some new code in ruleutils.c that was failing to cope with implicitly-casted joinaliasvars entries, as per recent report from Feike Steenbergen. That oversight was because of an inadequate description of the data structure in parsenodes.h, which I've now corrected. There were some pre-existing oversights of the same ilk elsewhere, which I believe are now all fixed. 23 July 2013, 20:23:16 UTC
a0dc922 Robert Haas 19 July 2013, 14:23:12 UTC doc: Fix typos in conversion names. David Christensen 19 July 2013, 14:54:34 UTC
ffb2855 Michael Meskes 19 July 2013, 06:59:20 UTC Initialize day of year value. There are cases where the day of year value in struct tm is used, but it never got calculated. Problem found by Coverity scan. 19 July 2013, 07:05:01 UTC
1a8a3f6 Tom Lane 19 July 2013, 01:22:58 UTC Fix regex match failures for backrefs combined with non-greedy quantifiers. An ancient logic error in cfindloop() could cause the regex engine to fail to find matches that begin later than the start of the string. This function is only used when the regex pattern contains a back reference, and so far as we can tell the error is only reachable if the pattern is non-greedy (i.e. its first quantifier uses the ? modifier). Furthermore, the actual match must begin after some potential match that satisfies the DFA but then fails the back-reference's match test. Reported and fixed by Jeevan Chalke, with cosmetic adjustments by me. 19 July 2013, 01:22:58 UTC
5174bc2 Stephen Frost 14 July 2013, 20:44:16 UTC Ensure 64bit arithmetic when calculating tapeSpace In tuplesort.c:inittapes(), we calculate tapeSpace by first figuring out how many 'tapes' we can use (maxTapes) and then multiplying the result by the tape buffer overhead for each. Unfortunately, when we are on a system with an 8-byte long, we allow work_mem to be larger than 2GB and that allows maxTapes to be large enough that the 32bit arithmetic can overflow when multiplied against the buffer overhead. When this overflow happens, we end up adding the overflow to the amount of space available, causing the amount of memory allocated to be larger than work_mem. Note that to reach this point, you have to set work mem to at least 24GB and be sorting a set which is at least that size. Given that a user who can set work_mem to 24GB could also set it even higher, if they were looking to run the system out of memory, this isn't considered a security issue. This overflow risk was found by the Coverity scanner. Back-patch to all supported branches, as this issue has existed since before 8.4. 14 July 2013, 20:44:16 UTC
9a785ac Magnus Hagander 07 July 2013, 11:36:20 UTC Fix include-guard Looks like a cut/paste error in the original addition of the file. Andres Freund 07 July 2013, 11:39:07 UTC
6b51f65 Michael Meskes 06 July 2013, 20:08:53 UTC Also escape double quotes for ECPG's #line statement. 06 July 2013, 20:12:32 UTC
d0d7125 Michael Meskes 05 July 2013, 09:07:16 UTC Applied patch by MauMau <maumau307@gmail.com> to escape filenames in #line statements. 05 July 2013, 09:15:30 UTC
1a1e797 Alvaro Herrera 02 July 2013, 16:21:16 UTC Mention extra_float_digits in floating point docs Make it easier for readers of the FP docs to find out about possibly truncated values. Per complaint from Tom Duffey in message F0E0F874-C86F-48D1-AA2A-0C5365BF5118@trillitech.com Author: Albe Laurenz Reviewed by: Abhijit Menon-Sen 02 July 2013, 17:14:02 UTC
76ce043 Tom Lane 27 June 2013, 17:55:09 UTC Mark index-constraint comments with correct dependency in pg_dump. When there's a comment on an index that was created with UNIQUE or PRIMARY KEY constraint syntax, we need to label the comment as depending on the constraint not the index, since only the constraint object actually appears in the dump. This incorrect dependency can lead to parallel pg_restore trying to restore the comment before the index has been created, per bug #8257 from Lloyd Albin. This patch fixes pg_dump to produce the right dependency in dumps made in the future. Usually we also try to hack pg_restore to work around bogus dependencies, so that existing (wrong) dumps can still be restored in parallel mode; but that doesn't seem practical here since there's no easy way to relate the constraint dump entry to the comment after the fact. Andres Freund 27 June 2013, 17:55:09 UTC
a5380bd Tom Lane 27 June 2013, 16:36:44 UTC Expect EWOULDBLOCK from a non-blocking connect() call only on Windows. On Unix-ish platforms, EWOULDBLOCK may be the same as EAGAIN, which is *not* a success return, at least not on Linux. We need to treat it as a failure to avoid giving a misleading error message. Per the Single Unix Spec, only EINPROGRESS and EINTR returns indicate that the connection attempt is in progress. On Windows, on the other hand, EWOULDBLOCK (WSAEWOULDBLOCK) is the expected case. We must accept EINPROGRESS as well because Cygwin will return that, and it doesn't seem worth distinguishing Cygwin from native Windows here. It's not very clear whether EINTR can occur on Windows, but let's leave that part of the logic alone in the absence of concrete trouble reports. Also, remove the test for errno == 0, effectively reverting commit da9501bddb42222dc33c031b1db6ce2133bcee7b, which AFAICS was just a thinko; or at best it might have been a workaround for a platform-specific bug, which we can hope is gone now thirteen years later. In any case, since libpq makes no effort to reset errno to zero before calling connect(), it seems unlikely that that test has ever reliably done anything useful. Andres Freund and Tom Lane 27 June 2013, 16:37:34 UTC
b02b5dc Tom Lane 27 June 2013, 04:28:01 UTC Tweak wording in sequence-function docs to avoid PDF build failures. Adjust the wording in the first para of "Sequence Manipulation Functions" so that neither of the link phrases in it break across line boundaries, in either A4- or US-page-size PDF output. This fixes a reported build failure for the 9.3beta2 A4 PDF docs, and future-proofs this particular para against causing similar problems in future. (Perhaps somebody will fix this issue in the SGML/TeX documentation tool chain someday, but I'm not holding my breath.) Back-patch to all supported branches, since the same problem could rise up to bite us in future updates if anyone changes anything earlier than this in func.sgml. 27 June 2013, 04:28:01 UTC
ca17001 Noah Misch 26 June 2013, 23:51:56 UTC Document effect of constant folding on CASE. Back-patch to all supported versions. Laurenz Albe 26 June 2013, 23:53:28 UTC
f44eedc Simon Riggs 23 June 2013, 10:05:02 UTC Ensure no xid gaps during Hot Standby startup In some cases with higher numbers of subtransactions it was possible for us to incorrectly initialize subtrans leading to complaints of missing pages. Bug report by Sergey Konoplev Analysis and fix by Andres Freund 23 June 2013, 13:50:38 UTC
4f1490c Peter Eisentraut 20 June 2013, 02:31:42 UTC Update CREATE FUNCTION documentation about argument names More languages than PL/pgSQL actually support parameter names. 20 June 2013, 02:33:07 UTC
4228bde Tom Lane 13 June 2013, 17:11:45 UTC Only install a portal's ResourceOwner if it actually has one. In most scenarios a portal without a ResourceOwner is dead and not subject to any further execution, but a portal for a cursor WITH HOLD remains in existence with no ResourceOwner after the creating transaction is over. In this situation, if we attempt to "execute" the portal directly to fetch data from it, we were setting CurrentResourceOwner to NULL, leading to a segfault if the datatype output code did anything that required a resource owner (such as trying to fetch system catalog entries that weren't already cached). The case appears to be impossible to provoke with stock libpq, but psqlODBC at least is able to cause it when working with held cursors. Simplest fix is to just skip the assignment to CurrentResourceOwner, so that any resources used by the data output operations will be managed by the transaction-level resource owner instead. For consistency I changed all the places that install a portal's resowner as current, even though some of them are probably not reachable with a held cursor's portal. Per report from Joshua Berry (with thanks to Hiroshi Inoue for developing a self-contained test case). Back-patch to all supported versions. 13 June 2013, 17:11:45 UTC
6803921 Robert Haas 12 June 2013, 16:20:59 UTC Improve description of loread/lowrite. Patch by me, reviewed by Tatsuo Ishii. 12 June 2013, 16:24:32 UTC
ca97a8d Tatsuo Ishii 11 June 2013, 05:25:58 UTC Add description that loread()/lowrite() are corresponding to lo_read()/lo_write() in libpq to avoid confusion. 11 June 2013, 05:29:44 UTC
f80872b Tom Lane 09 June 2013, 22:39:39 UTC Remove unnecessary restrictions about RowExprs in transformAExprIn(). When the existing code here was written, it made sense to special-case RowExprs because that was the only way that we could handle row comparisons at all. Now that we have record_eq() and arrays of composites, the generic logic for "scalar" types will in fact work on RowExprs too, so there's no reason to throw error for combinations of RowExprs and other ways of forming composite values, nor to ignore the possibility of using a ScalarArrayOpExpr. But keep using the old logic when comparing two RowExprs, for consistency with the main transformAExprOp() logic. (This allows some cases with not-quite-identical rowtypes to succeed, so we might get push-back if we removed it.) Per bug #8198 from Rafal Rzepecki. Back-patch to all supported branches, since this works fine as far back as 8.4. Rafal Rzepecki and Tom Lane 09 June 2013, 22:39:39 UTC
1476a94 Tom Lane 09 June 2013, 19:27:00 UTC Remove ALTER DEFAULT PRIVILEGES' requirement of schema CREATE permissions. Per discussion, this restriction isn't needed for any real security reason, and it seems to confuse people more often than it helps them. It could also result in some database states being unrestorable. So just drop it. Back-patch to 9.0, where ALTER DEFAULT PRIVILEGES was introduced. 09 June 2013, 19:27:00 UTC
489be9c Andrew Dunstan 08 June 2013, 14:20:37 UTC Don't downcase non-ascii identifier chars in multi-byte encodings. Long-standing code has called tolower() on identifier character bytes with the high bit set. This is clearly an error and produces junk output when the encoding is multi-byte. This patch therefore restricts this activity to cases where there is a character with the high bit set AND the encoding is single-byte. There have been numerous gripes about this, most recently from Martin Schäfer. Backpatch to all live releases. 08 June 2013, 14:20:37 UTC
88ce29a Kevin Grittner 07 June 2013, 14:13:39 UTC Correct the documentation of pg_rewrite.ev_attr. It claimed the value was always zero; it is really always -1. Per report from Hari Babu backpatch 734fbbd1d2d1babfbd195414e2445024ad549ae3 to 8.4 07 June 2013, 14:13:39 UTC
c9d9a22 Tom Lane 07 June 2013, 04:08:02 UTC Minor docs wordsmithing. Swap the order of a couple of phrases to clarify what the adjective "subsequent" applies to. Joshua Tolley 07 June 2013, 04:08:53 UTC
62bcc1c Heikki Linnakangas 06 June 2013, 15:25:26 UTC Fix typo in comment. 06 June 2013, 15:26:18 UTC
b94b9e4 Tom Lane 06 June 2013, 03:44:19 UTC Prevent pushing down WHERE clauses into unsafe UNION/INTERSECT nests. The planner is aware that it mustn't push down upper-level quals into subqueries if the quals reference subquery output columns that contain set-returning functions or volatile functions, or are non-DISTINCT outputs of a DISTINCT ON subquery. However, it missed making this check when there were one or more levels of UNION or INTERSECT above the dangerous expression. This could lead to "set-valued function called in context that cannot accept a set" errors, as seen in bug #8213 from Eric Soroos, or to silently wrong answers in the other cases. To fix, refactor the checks so that we make the column-is-unsafe checks during subquery_is_pushdown_safe(), which already has to recursively inspect all arms of a set-operation tree. This makes qual_is_pushdown_safe() considerably simpler, at the cost that we will spend some cycles checking output columns that possibly aren't referenced in any upper qual. But the cases where this code gets executed at all are already nontrivial queries, so it's unlikely anybody will notice any slowdown of planning. This has been broken since commit 05f916e6add9726bf4ee046e4060c1b03c9961f2, which makes the bug over ten years old. A bit surprising nobody noticed it before now. 06 June 2013, 03:44:19 UTC
53eb835 Tom Lane 05 June 2013, 17:32:53 UTC Put analyze_keyword back in explain_option_name production. In commit 2c92edad48796119c83d7dbe6c33425d1924626d, I broke "EXPLAIN (ANALYZE)" syntax, because I mistakenly thought that ANALYZE/ANALYSE were only partially reserved and thus would be included in NonReservedWord; but actually they're fully reserved so they still need to be called out here. A nicer solution would be to demote these words to type_func_name_keyword status (they can't be less than that because of "VACUUM [ANALYZE] ColId"). While that works fine so far as the core grammar is concerned, it breaks ECPG's grammar for reasons I don't have time to isolate at the moment. So do this for the time being. Per report from Kevin Grittner. Back-patch to 9.0, like the previous commit. 05 June 2013, 17:33:33 UTC
c28bfb3 Tom Lane 04 June 2013, 18:59:02 UTC Fix memory leak in LogStandbySnapshot(). The array allocated by GetRunningTransactionLocks() needs to be pfree'd when we're done with it. Otherwise we leak some memory during each checkpoint, if wal_level = hot_standby. This manifests as memory bloat in the checkpointer process, or in bgwriter in versions before we made the checkpointer separate. Reported and fixed by Naoya Anzai. Back-patch to 9.0 where the issue was introduced. In passing, improve comments for GetRunningTransactionLocks(), and add an Assert that we didn't overrun the palloc'd array. 04 June 2013, 18:59:02 UTC
bb5a217 Tom Lane 03 June 2013, 18:19:44 UTC Add semicolons to eval'd strings to hide a minor Perl behavioral change. "eval q{foo}" used to complain that the error was on line 2 of the eval'd string, because eval internally tacked on "\n;" so that the end of the erroneous command was indeed on line 2. But as of Perl 5.18 it more sanely says that the error is on line 1. To avoid Perl-version-dependent regression test results, use "eval q{foo;}" instead in the two places where this matters. Per buildfarm. Since people might try to use newer Perl versions with older PG releases, back-patch as far as 9.0 where these test cases were added. 03 June 2013, 18:19:44 UTC
805730d Tom Lane 03 June 2013, 00:09:37 UTC Allow type_func_name_keywords in some places where they weren't before. This change makes type_func_name_keywords less reserved than they were before, by allowing them for role names, language names, EXPLAIN and COPY options, and SET values for GUCs; which are all places where few if any actual keywords could appear instead, so no new ambiguities are introduced. The main driver for this change is to allow "COPY ... (FORMAT BINARY)" to work without quoting the word "binary". That is an inconsistency that has been complained of repeatedly over the years (at least by Pavel Golub, Kurt Lidl, and Simon Riggs); but we hadn't thought of any non-ugly solution until now. Back-patch to 9.0 where the COPY (FORMAT BINARY) syntax was introduced. 03 June 2013, 00:09:37 UTC
1b192fc Tom Lane 16 May 2013, 19:04:54 UTC Fix fd.c to preserve errno where needed. PathNameOpenFile failed to ensure that the correct value of errno was returned to its caller after a failure (because it incorrectly supposed that free() can never change errno). In some cases this would result in a user-visible failure because an expected ENOENT errno was replaced with something else. Bogus EINVAL failures have been observed on OS X, for example. There were also a couple of places that could mangle an important value of errno if FDDEBUG was defined. While the usefulness of that debug support is highly debatable, we might as well make it safe to use, so add errno save/restore logic to the DO_DB macro. Per bug #8167 from Nelson Minar, diagnosed by RhodiumToad. Back-patch to all supported branches. 16 May 2013, 19:04:54 UTC
e150773 Tom Lane 13 May 2013, 19:40:16 UTC Fix handling of OID wraparound while in standalone mode. If OID wraparound should occur while in standalone mode (unlikely but possible), we want to advance the counter to FirstNormalObjectId not FirstBootstrapObjectId. Otherwise, user objects might be created with OIDs in the system-reserved range. That isn't immediately harmful but it poses a risk of conflicts during future pg_upgrade operations. Noted by Andres Freund. Back-patch to all supported branches, since all of them are supported sources for pg_upgrade operations. 13 May 2013, 19:41:04 UTC
dbd68df Tom Lane 10 May 2013, 21:15:51 UTC Guard against input_rows == 0 in estimate_num_groups(). This case doesn't normally happen, because the planner usually clamps all row estimates to at least one row; but I found that it can arise when dealing with relations excluded by constraints. Without a defense, estimate_num_groups() can return zero, which leads to divisions by zero inside the planner as well as assertion failures in the executor. An alternative fix would be to change set_dummy_rel_pathlist() to make the size estimate for a dummy relation 1 row instead of 0, but that seemed pretty ugly; and probably someday we'll want to drop the convention that the minimum rowcount estimate is 1 row. Back-patch to 8.4, as the problem can be demonstrated that far back. 10 May 2013, 21:15:51 UTC
53cdc3e Tom Lane 10 May 2013, 17:07:02 UTC Fix pgp_pub_decrypt() so it works for secret keys with passwords. Per report from Keith Fiske. Marko Kreen 10 May 2013, 17:07:02 UTC
f9b604e Bruce Momjian 04 May 2013, 17:15:54 UTC docs: log_line_prefix session id fix Restore 4-byte designation for docs. Fix 9.3 doc query to properly pad to four digits. Backpatch to all active branches Per suggestions from Ian Lawrence Barwick 04 May 2013, 17:15:54 UTC
db5fa1d Bruce Momjian 04 May 2013, 15:09:44 UTC doc: fix log_line_prefix session_id %c item Backpatch to 9.1 and earlier Report from Ian Lawrence Barwick 04 May 2013, 15:09:44 UTC
5f14acd Heikki Linnakangas 02 May 2013, 15:08:43 UTC Fix thinko in comment. WAL segment means a 16 MB physical WAL file; this comment meant a logical 4 GB log file. Amit Langote. Apply to backbranches only, as the comment is gone in master. 02 May 2013, 15:11:18 UTC
2751c7f Kevin Grittner 29 April 2013, 18:06:49 UTC Ensure ANALYZE phase is not skipped because of canceled truncate. Patch b19e4250b45e91c9cbdd18d35ea6391ab5961c8d attempted to preserve existing behavior regarding statistics generation in the case that a truncation attempt was canceled due to lock conflicts. It failed to do this accurately in two regards: (1) autovacuum had previously generated statistics if the truncate attempt failed to initially get the lock rather than having started the attempt, and (2) the VACUUM ANALYZE command had always generated statistics. Both of these changes were unintended, and are reverted by this patch. On review, there seems to be consensus that the previous failure to generate statistics when the truncate was terminated was more an unfortunate consequence of how that effort was previously terminated than a feature we want to keep; so this patch generates statistics even when an autovacuum truncation attempt terminates early. Another unintended change which is kept on the basis that it is an improvement is that when a VACUUM command is truncating, it will the new heuristic for avoiding blocking other processes, rather than keeping an AccessExclusiveLock on the table for however long the truncation takes. Per multiple reports, with some renaming per patch by Jeff Janes. Backpatch to 9.0, where problem was created. 29 April 2013, 18:06:49 UTC
0dcff75 Tom Lane 25 April 2013, 20:58:19 UTC Avoid deadlock between concurrent CREATE INDEX CONCURRENTLY commands. There was a high probability of two or more concurrent C.I.C. commands deadlocking just before completion, because each would wait for the others to release their reference snapshots. Fix by releasing the snapshot before waiting for other snapshots to go away. Per report from Paul Hinze. Back-patch to all active branches. 25 April 2013, 20:58:19 UTC
fe1d8c1 Heikki Linnakangas 25 April 2013, 11:03:10 UTC Fix typo in comment. Peter Geoghegan 25 April 2013, 11:08:08 UTC
dd9c6ff Tom Lane 20 April 2013, 20:59:36 UTC Fix longstanding race condition in plancache.c. When creating or manipulating a cached plan for a transaction control command (particularly ROLLBACK), we must not perform any catalog accesses, since we might be in an aborted transaction. However, plancache.c busily saved or examined the search_path for every cached plan. If we were unlucky enough to do this at a moment where the path's expansion into schema OIDs wasn't already cached, we'd do some catalog accesses; and with some more bad luck such as an ill-timed signal arrival, that could lead to crashes or Assert failures, as exhibited in bug #8095 from Nachiket Vaidya. Fortunately, there's no real need to consider the search path for such commands, so we can just skip the relevant steps when the subject statement is a TransactionStmt. This is somewhat related to bug #5269, though the failure happens during initial cached-plan creation rather than revalidation. This bug has been there since the plan cache was invented, so back-patch to all supported branches. 20 April 2013, 20:59:36 UTC
8e00c48 Peter Eisentraut 05 April 2013, 01:14:21 UTC doc: Fix number of columns in table 05 April 2013, 01:15:14 UTC
back to top