| 8c72b20 | Tom Lane | 29 November 2013, 23:34:18 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:18 UTC |
| bf0d21e | 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:44:10 UTC |
| 9a1c6dd | Michael Meskes | 27 November 2013, 10:02:13 UTC | ECPG: Fix searching for quoted cursor names case-sensitively. Patch by Böszörményi Zoltán <zb@cybertec.at> | 27 November 2013, 10:15:34 UTC |
| a172699 | Michael Meskes | 27 November 2013, 10:03:59 UTC | Documentation fix for ecpg. The latest fixes removed a limitation that was still in the docs, so Zoltan updated the docs, too. | 27 November 2013, 10:15:32 UTC |
| 375ed99 | Fujii Masao | 27 November 2013, 04:45:41 UTC | Fix typo in release note. Backpatch to 9.1. Josh Kupershmidt | 27 November 2013, 04:45:41 UTC |
| 5bffd42 | 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> | 26 November 2013, 16:32:06 UTC |
| 20ada26 | 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:32:02 UTC |
| 8bf45ea | 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:11 UTC |
| 7b63528 | Tom Lane | 24 November 2013, 01:04:06 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:06 UTC |
| b2502ec | 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:50 UTC |
| e1f7173 | 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:07 UTC |
| 92a7521 | Tom Lane | 22 November 2013, 19:37:31 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:31 UTC |
| 6730199 | Tom Lane | 22 November 2013, 17:07:53 UTC | Fix quoting in help messages in uuid-ossp extension scripts. The command we're telling people to type needs to include double-quoting around the unfortunately-chosen extension name. Twiddle the textual quoting so that it looks somewhat sane. Per gripe from roadrunner6. | 22 November 2013, 17:08:22 UTC |
| fc8e54f | 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:48:55 UTC |
| e3a02a3 | 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:30 UTC |
| 71ff6c1 | 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:47 UTC |
| 29bbca4 | 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:33 UTC |
| 3527a5f | 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:14 UTC |
| af38d14 | Tom Lane | 08 November 2013, 16:37:08 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:08 UTC |
| 8cfd4c6 | Tom Lane | 07 November 2013, 21:33:28 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:28 UTC |
| 6e2c762 | Tom Lane | 07 November 2013, 18:13:47 UTC | Fix generation of MergeAppend plans for optimized min/max on expressions. Before jamming a desired targetlist into a plan node, one really ought to make sure the plan node can handle projections, and insert a buffering Result plan node if not. planagg.c forgot to do this, which is a hangover from the days when it only dealt with IndexScan plan types. MergeAppend doesn't project though, not to mention that it gets unhappy if you remove its possibly-resjunk sort columns. The code accidentally failed to fail for cases in which the min/max argument was a simple Var, because the new targetlist would be equivalent to the original "flat" tlist anyway. For any more complex case, it's been broken since 9.1 where we introduced the ability to optimize min/max using MergeAppend, as reported by Raphael Bauduin. Fix by duplicating the logic from grouping_planner that decides whether we need a Result node. In 9.2 and 9.1, this requires back-porting the tlist_same_exprs() function introduced in commit 4387cf956b9eb13aad569634e0c4df081d76e2e3, else we'd uselessly add a Result node in cases that worked before. It's rather tempting to back-patch that whole commit so that we can avoid extra Result nodes in mainline cases too; but I'll refrain, since that code hasn't really seen all that much field testing yet. | 07 November 2013, 18:13:47 UTC |
| aad87e3 | Tom Lane | 06 November 2013, 18:32:26 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:26 UTC |
| db157fb | Tom Lane | 06 November 2013, 02:58:19 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:19 UTC |
| 4c412ca | Michael Meskes | 03 November 2013, 14:37:34 UTC | Changed test case slightly so it doesn't have an unused typedef. | 03 November 2013, 14:40:19 UTC |
| 8c0116a | Tom Lane | 01 November 2013, 20:10:00 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:00 UTC |
| 172ba45 | Tom Lane | 01 November 2013, 16:13:29 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:29 UTC |
| 4bf70c0 | Tom Lane | 29 October 2013, 00:49:35 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:35 UTC |
| e78ed04 | 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:31 UTC |
| 38ee3c5 | Bruce Momjian | 15 October 2013, 14:34:04 UTC | docs: correct 9.1 and 9.2 release note mention of timeline switch fix Backpatch through 9.1. KONDO Mitsumasa | 15 October 2013, 14:34:04 UTC |
| 6defa66 | 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 |
| b444726 | Peter Eisentraut | 08 October 2013, 03:13:47 UTC | Stamp 9.1.10. | 08 October 2013, 03:13:47 UTC |
| 4a72c60 | Peter Eisentraut | 08 October 2013, 02:41:53 UTC | Revert "Document support for VPATH builds of extensions." This reverts commit 6ed3c5f7b2846be9e176ea1c99b2d45bba0d6972. | 08 October 2013, 02:41:53 UTC |
| 791a71a | Peter Eisentraut | 08 October 2013, 02:39:30 UTC | Revert "Backpatch pgxs vpath build and installation fixes (v2)" This reverts commit 176c70b9f2ce382a5590e42afd7ba4edb87efecb. pending resolution of http://www.postgresql.org/message-id/1381193255.25702.4.camel@vanquo.pezone.net | 08 October 2013, 02:39:30 UTC |
| 56e90da | 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 |
| d818551 | Heikki Linnakangas | 08 October 2013, 00:49:08 UTC | Oops. Unbreak the 9.1 build. I forgot to "git add" latest changes after backpatching the changes for previous commit. | 08 October 2013, 00:49:08 UTC |
| 42c63ca | Heikki Linnakangas | 07 October 2013, 20:57:40 UTC | Fix bugs in SSI tuple locking. 1. In heap_hot_search_buffer(), the PredicateLockTuple() call is passed wrong offset number. heapTuple->t_self is set to the tid of the first tuple in the chain that's visited, not the one actually being read. 2. CheckForSerializableConflictIn() uses the tuple's t_ctid field instead of t_self to check for exiting predicate locks on the tuple. If the tuple was updated, but the updater rolled back, t_ctid points to the aborted dead tuple. Reported by Hannu Krosing. Backpatch to 9.1. | 07 October 2013, 21:14:15 UTC |
| 1c4dfd1 | Peter Eisentraut | 07 October 2013, 20:15:26 UTC | Translation updates | 07 October 2013, 20:15:26 UTC |
| 556e6d0 | Kevin Grittner | 07 October 2013, 19:05:26 UTC | Eliminate xmin from hash tag for predicate locks on heap tuples. If a tuple was frozen while its predicate locks mattered, read-write dependencies could be missed, resulting in failure to detect conflicts which could lead to anomalies in committed serializable transactions. This field was added to the tag when we still thought that it was necessary to carry locks forward to a new version of an updated row. That was later proven to be unnecessary, which allowed simplification of the code, but elimination of xmin from the tag was missed at the time. Per report and analysis by Heikki Linnakangas. Backpatch to 9.1. | 07 October 2013, 19:05:26 UTC |
| 6ed3c5f | Andrew Dunstan | 07 October 2013, 03:07:28 UTC | Document support for VPATH builds of extensions. Cédric Villemain and me. | 07 October 2013, 03:07:28 UTC |
| d648af0 | Peter Eisentraut | 03 October 2013, 01:33:26 UTC | doc: Correct psycopg URL | 03 October 2013, 01:34:28 UTC |
| c768cf6 | Peter Eisentraut | 03 October 2013, 01:25:39 UTC | pg_basebackup: Add missing newline to error message | 03 October 2013, 01:25:39 UTC |
| 176c70b | Andrew Dunstan | 30 September 2013, 14:45:40 UTC | Backpatch pgxs vpath build and installation fixes (v2) This time with the better installation fix, which I hope won't break the buildfarm. | 30 September 2013, 14:45:40 UTC |
| cd6c03b | 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:55:57 UTC |
| 03b6a6b | Andrew Dunstan | 30 September 2013, 04:08:37 UTC | Revert "Backpatch pgxs vpath build and installation fixes." This reverts commit 15892461042f4e00322f4116236697dde022a2f8. | 30 September 2013, 04:08:37 UTC |
| 1589246 | Andrew Dunstan | 29 September 2013, 21:33:02 UTC | Backpatch pgxs vpath build and installation fixes. This is a backpatch of commits d942f9d9, 82b01026, and 6697aa2bc, back to release 9.1 where we introduced extensions which make heavy use of the PGXS infrastructure. | 29 September 2013, 21:33:02 UTC |
| 096ad24 | 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:10 UTC |
| 1e69158 | Alvaro Herrera | 24 September 2013, 21:19:14 UTC | Fix pgindent comment breakage | 24 September 2013, 21:21:20 UTC |
| ea0a8f0 | Noah Misch | 23 September 2013, 20:00:13 UTC | Use @libdir@ in both of regress/{input,output}/security_label.source Though @libdir@ almost always matches @abs_builddir@ in this context, the test could only fail if they differed. Back-patch to 9.1, where the test was introduced. Hamid Quddus Akhtar | 23 September 2013, 20:01:04 UTC |
| 5eaa369 | 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:04 UTC |
| f0d76a5 | 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:29 UTC |
| 994362a | 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:22 UTC |
| aef9d25 | 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:22 UTC |
| 8e67a28 | Tom Lane | 03 September 2013, 22:32:29 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:29 UTC |
| f873073 | 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:38 UTC |
| c558e1e | Andrew Dunstan | 02 September 2013, 18:36:08 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:36:08 UTC |
| b828803 | Andrew Dunstan | 26 August 2013, 18:55:00 UTC | Unconditionally use the WSA equivalents of Socket error constants. This change will only apply to mingw compilers, and has been found necessary by late versions of the mingw-w64 compiler. It's the same as what is done elsewhere for the Microsoft compilers. Backpatch of commit 73838b5251e. Problem reported by Michael Cronenworth, although not his patch. | 26 August 2013, 18:55:00 UTC |
| f7bbd46 | Tom Lane | 23 August 2013, 21:31:03 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:03 UTC |
| 649839d | Tom Lane | 21 August 2013, 22:31:48 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:48 UTC |
| a2e66c0 | Peter Eisentraut | 18 August 2013, 01:46:32 UTC | libpq: Report strerror on pthread_mutex_lock() failure | 18 August 2013, 01:52:35 UTC |
| 6084c07 | Tom Lane | 03 August 2013, 16:39:57 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:45 UTC |
| c928dc9 | 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:08 UTC |
| 7112775 | 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:46 UTC |
| 0b821b8 | 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:01 UTC |
| 1346f40 | Tom Lane | 31 July 2013, 15:31:33 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:33 UTC |
| ed33ad3 | 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. | 30 July 2013, 23:41:53 UTC |
| aa49821 | Tom Lane | 29 July 2013, 14:42:47 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:47 UTC |
| 3ba763b | Tom Lane | 25 July 2013, 15:39:18 UTC | Fix configure probe for sys/ucred.h. The configure script's test for <sys/ucred.h> did not work on OpenBSD, because on that platform <sys/param.h> has to be included first. As a result, socket peer authentication was disabled on that platform. Problem introduced in commit be4585b1c27ac5dbdd0d61740d18f7ad9a00e268. Andres Freund, slightly simplified by me. | 25 July 2013, 15:39:18 UTC |
| 13f11c8 | 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:46 UTC |
| 15fdf73 | 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 |
| c1f51ed | Tom Lane | 23 July 2013, 20:23:11 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:11 UTC |
| e23adef | Robert Haas | 19 July 2013, 14:23:12 UTC | doc: Fix typos in conversion names. David Christensen | 19 July 2013, 14:54:26 UTC |
| 4652abe | 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:18 UTC |
| f4ceb7a | Tom Lane | 19 July 2013, 01:22:53 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:53 UTC |
| 2f397a0 | Stephen Frost | 15 July 2013, 15:27:20 UTC | Clean up pg_basebackup libpq usage When using libpq, it's generally preferrable to just use the strings which are in the PQ structures instead of copying them out, so do that instead in BaseBackup(), eliminating the strcpy()'s used there. Also, in ReceiveAndUnpackTarFile(), check the string length for the directory returned by the server for the tablespace path. | 15 July 2013, 15:27:20 UTC |
| 3cb7a39 | Stephen Frost | 14 July 2013, 20:43:47 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:43:47 UTC |
| 703bc14 | Michael Meskes | 27 June 2013, 14:00:32 UTC | Fixed incorrect description of EXEC SQL VAR command. Thanks to MauMau <maumau307@gmail.com> for finding and fixing this. | 12 July 2013, 13:03:52 UTC |
| ad4c625 | Bruce Momjian | 11 July 2013, 13:43:15 UTC | pg_upgrade: document possible pg_hba.conf options Previously, pg_upgrade docs recommended using .pgpass if using MD5 authentication to avoid being prompted for a password. Turns out pg_ctl never prompts for a password, so MD5 requires .pgpass --- document that. Also recommend 'peer' for authentication too. Backpatch back to 9.1. | 11 July 2013, 13:43:15 UTC |
| 271f7b0 | 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:38:57 UTC |
| 6dc4e62 | Michael Meskes | 06 July 2013, 20:08:53 UTC | Also escape double quotes for ECPG's #line statement. | 06 July 2013, 20:12:14 UTC |
| 456d37a | Magnus Hagander | 05 July 2013, 14:22:45 UTC | Remove stray | character Erikjan Rijkers | 05 July 2013, 14:22:45 UTC |
| 2bb2a29 | 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:19 UTC |
| 8455b70 | 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 |
| 50e66d3 | Tom Lane | 27 June 2013, 17:55:04 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:04 UTC |
| c204aba | 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:20 UTC |
| 0ae7d63 | Tom Lane | 27 June 2013, 04:27:26 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:27:26 UTC |
| 8356d94 | Noah Misch | 26 June 2013, 23:51:56 UTC | Document effect of constant folding on CASE. Back-patch to all supported versions. Laurenz Albe | 27 June 2013, 00:33:47 UTC |
| 1c6afc4 | Andrew Dunstan | 25 June 2013, 17:44:34 UTC | Properly dump dropped foreign table cols in binary-upgrade mode. In binary upgrade mode, we need to recreate and then drop dropped columns so that all the columns get the right attribute number. This is true for foreign tables as well as for native tables. For foreign tables we have been getting the first part right but not the second, leading to bogus columns in the upgraded database. Fix this all the way back to 9.1, where foreign tables were introduced. | 25 June 2013, 17:44:34 UTC |
| 3f145f6 | Fujii Masao | 25 June 2013, 17:20:11 UTC | Support clean switchover. In replication, when we shutdown the master, walsender tries to send all the outstanding WAL records to the standby, and then to exit. This basically means that all the WAL records are fully synced between two servers after the clean shutdown of the master. So, after promoting the standby to new master, we can restart the stopped master as new standby without the need for a fresh backup from new master. But there was one problem so far: though walsender tries to send all the outstanding WAL records, it doesn't wait for them to be replicated to the standby. Then, before receiving all the WAL records, walreceiver can detect the closure of connection and exit. We cannot guarantee that there is no missing WAL in the standby after clean shutdown of the master. In this case, backup from new master is required when restarting the stopped master as new standby. This patch fixes this problem. It just changes walsender so that it waits for all the outstanding WAL records to be replicated to the standby before closing the replication connection. Per discussion, this is a fix that needs to get backpatched rather than new feature. So, back-patch to 9.1 where enough infrastructure for this exists. Patch by me, reviewed by Andres Freund. | 25 June 2013, 17:20:11 UTC |
| a41c881 | 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:17 UTC |
| 27e9e86 | 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:31:42 UTC |
| be039d4 | Simon Riggs | 18 June 2013, 11:05:48 UTC | Fix docs on lock level for ALTER TABLE VALIDATE ALTER TABLE .. VALIDATE CONSTRAINT previously gave incorrect details about lock levels and therefore incomplete reasons to use the option. Initial bug report and fix from Marko Tiikkaja Reworded by me to include comments by Kevin Grittner | 18 June 2013, 11:05:48 UTC |
| 81bb2d2 | Fujii Masao | 15 June 2013, 20:15:44 UTC | Fix pg_restore -l with the directory archive to display the correct format name. Back-patch to 9.1 where the directory archive was introduced. | 15 June 2013, 20:15:44 UTC |
| cf0f08e | Tom Lane | 13 June 2013, 17:11:40 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:40 UTC |
| e19c932 | 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:21:57 UTC |
| e46753e | Tom Lane | 11 June 2013, 21:26:53 UTC | Fix cache flush hazard in cache_record_field_properties(). We need to increment the refcount on the composite type's cached tuple descriptor while we do lookups of its column types. Otherwise a cache flush could occur and release the tuple descriptor before we're done with it. This fails reliably with -DCLOBBER_CACHE_ALWAYS, but the odds of a failure in a production build seem rather low (since the pfree'd descriptor typically wouldn't get scribbled on immediately). That may explain the lack of any previous reports. Buildfarm issue noted by Christian Ullrich. Back-patch to 9.1 where the bogus code was added. | 11 June 2013, 21:26:53 UTC |
| 219ef8e | 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:25 UTC |
| 86742ac | Joe Conway | 10 June 2013, 00:31:51 UTC | Fix ordering of obj id for Rules and EventTriggers in pg_dump. getSchemaData() must identify extension member objects and mark them as not to be dumped. This must happen after reading all objects that can be direct members of extensions, but before we begin to process table subsidiary objects. Both rules and event triggers were wrong in this regard. Backport rules portion of patch to 9.1 -- event triggers do not exist prior to 9.3. Suggested fix by Tom Lane, initial complaint and patch by me. | 10 June 2013, 00:31:51 UTC |
| a2c2336 | Tom Lane | 09 June 2013, 22:39:34 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:34 UTC |
| aee8a60 | Tom Lane | 09 June 2013, 19:26:55 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:26:55 UTC |
| 8c3fdbb | Tom Lane | 09 June 2013, 17:47:06 UTC | Remove fixed limit on the number of concurrent AllocateFile() requests. AllocateFile(), AllocateDir(), and some sister routines share a small array for remembering requests, so that the files can be closed on transaction failure. Previously that array had a fixed size, MAX_ALLOCATED_DESCS (32). While historically that had seemed sufficient, Steve Toutant pointed out that this meant you couldn't scan more than 32 file_fdw foreign tables in one query, because file_fdw depends on the COPY code which uses AllocateFile(). There are probably other cases, or will be in the future, where this nonconfigurable limit impedes users. We can't completely remove any such limit, at least not without a lot of work, since each such request requires a kernel file descriptor and most platforms limit the number we can have. (In principle we could "virtualize" these descriptors, as fd.c already does for the main VFD pool, but not without an additional layer of overhead and a lot of notational impact on the calling code.) But we can at least let the array size be configurable. Hence, change the code to allow up to max_safe_fds/2 allocated file requests. On modern platforms this should allow several hundred concurrent file_fdw scans, or more if one increases the value of max_files_per_process. To go much further than that, we'd need to do some more work on the data structure, since the current code for closing requests has potentially O(N^2) runtime; but it should still be all right for request counts in this range. Back-patch to 9.1 where contrib/file_fdw was introduced. | 09 June 2013, 17:47:06 UTC |
