Skip to main content

Browse the archive

https://github.com/postgres/postgres
02 May 2024, 11:03:54 UTC
sort by:
Revision Author Date Message Commit Date
8b47c9d Tom Lane 02 December 2013, 21:00:18 UTC Stamp 9.2.6. 02 December 2013, 21:00:18 UTC
4993336 Tom Lane 02 December 2013, 20:54:01 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:01 UTC
715f44b Alvaro Herrera 02 December 2013, 16:28:24 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:24 UTC
ff61dd2 Peter Eisentraut 02 December 2013, 05:08:10 UTC Translation updates 02 December 2013, 05:08:10 UTC
c89acb4 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:05 UTC
9aa888e 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:31 UTC
27b3324 Kevin Grittner 30 November 2013, 17:33:54 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, 17:33:54 UTC
8f8c666 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, 00:59:15 UTC
19af7d4 Tom Lane 29 November 2013, 23:34:14 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:14 UTC
f0e3e05 Tom Lane 29 November 2013, 22:35:15 UTC Be sure to release proc->backendLock after SetupLockInTable() failure. The various places that transferred fast-path locks to the main lock table neglected to release the PGPROC's backendLock if SetupLockInTable failed due to being out of shared memory. In most cases this is no big deal since ensuing error cleanup would release all held LWLocks anyway. But there are some hot-standby functions that don't consider failure of FastPathTransferRelationLocks to be a hard error, and in those cases this oversight could lead to system lockup. For consistency, make all of these places look the same as FastPathTransferRelationLocks. Noted while looking for the cause of Dan Wood's bugs --- this wasn't it, but it's a bug anyway. 29 November 2013, 22:35:15 UTC
9457508 Tom Lane 28 November 2013, 17:17:53 UTC Fix latent(?) race condition in LockReleaseAll. We have for a long time checked the head pointer of each of the backend's proclock lists and skipped acquiring the corresponding locktable partition lock if the head pointer was NULL. This was safe enough in the days when proclock lists were changed only by the owning backend, but it is pretty questionable now that the fast-path patch added cases where backends add entries to other backends' proclock lists. However, we don't really wish to revert to locking each partition lock every time, because in simple transactions that would add a lot of useless lock/unlock cycles on already-heavily-contended LWLocks. Fortunately, the only way that another backend could be modifying our proclock list at this point would be if it was promoting a formerly fast-path lock of ours; and any such lock must be one that we'd decided not to delete in the previous loop over the locallock table. So it's okay if we miss seeing it in this loop; we'd just decide not to delete it again. However, once we've detected a non-empty list, we'd better re-fetch the list head pointer after acquiring the partition lock. This guards against possibly fetching a corrupt-but-non-null pointer if pointer fetch/store isn't atomic. It's not clear if any practical architectures are like that, but we've never assumed that before and don't wish to start here. In any case, the situation certainly deserves a code comment. While at it, refactor the partition traversal loop to use a for() construct instead of a while() loop with goto's. Back-patch, just in case the risk is real and not hypothetical. 28 November 2013, 17:17:53 UTC
62e69cb Peter Eisentraut 28 November 2013, 02:50:27 UTC doc: Put data types in alphabetical order From: Andreas Karlsson <andreas@proxel.se> 28 November 2013, 02:52:05 UTC
024edb4 Tom Lane 27 November 2013, 23:10:06 UTC Fix stale-pointer problem in fast-path locking logic. When acquiring a lock in fast-path mode, we must reset the locallock object's lock and proclock fields to NULL. They are not necessarily that way to start with, because the locallock could be left over from a failed lock acquisition attempt earlier in the transaction. Failure to do this led to all sorts of interesting misbehaviors when LockRelease tried to clean up no-longer-related lock and proclock objects in shared memory. Per report from Dan Wood. In passing, modify LockRelease to elog not just Assert if it doesn't find lock and proclock objects for a formerly fast-path lock, matching the code in FastPathGetRelationLockEntry and LockRefindAndRelease. This isn't a bug but it will help in diagnosing any future bugs in this area. Also, modify FastPathTransferRelationLocks and FastPathGetRelationLockEntry to break out of their loops over the fastpath array once they've found the sole matching entry. This was inconsistently done in some search loops and not others. Improve assorted related comments, too. Back-patch to 9.2 where the fast-path mechanism was introduced. 27 November 2013, 23:10:06 UTC
0b132b9 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:28:47 UTC
0cedfa7 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:13 UTC
6bb2972 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:09 UTC
744fa4d Fujii Masao 27 November 2013, 04:45:41 UTC Fix typo in release note. Backpatch to 9.1. Josh Kupershmidt 27 November 2013, 04:46:19 UTC
b05c415 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:26 UTC
0aec900 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:24 UTC
b6da09f 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:08 UTC
96ac8b5 Tom Lane 24 November 2013, 01:04:03 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:03 UTC
e86f2a0 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:46 UTC
654e006 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:30:45 UTC
c0aa210 Tom Lane 22 November 2013, 19:37:29 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:29 UTC
2583fa8 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:19 UTC
f22624c 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:43 UTC
3379263 Heikki Linnakangas 18 November 2013, 07:51:09 UTC Count locked pages that don't need vacuuming as scanned. Previously, if VACUUM skipped vacuuming a page because it's pinned, it didn't count that page as scanned. However, that meant that relfrozenxid was not bumped up either, which prevented anti-wraparound vacuum from doing its job. Report by Миша Тюрин, analysis and patch by Sergey Burladyn and Jeff Janes. Backpatch to 9.2, where the skip-locked-pages behavior was introduced. 18 November 2013, 08:12:22 UTC
b18882a 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:26 UTC
51b6ae6 Tom Lane 15 November 2013, 21:46:25 UTC Compute correct em_nullable_relids in get_eclass_for_sort_expr(). Bug #8591 from Claudio Freire demonstrates that get_eclass_for_sort_expr must be able to compute valid em_nullable_relids for any new equivalence class members it creates. I'd worried about this in the commit message for db9f0e1d9a4a0842c814a464cdc9758c3f20b96c, but claimed that it wasn't a problem because multi-member ECs should already exist when it runs. That is transparently wrong, though, because this function is also called by initialize_mergeclause_eclasses, which runs during deconstruct_jointree. The example given in the bug report (which the new regression test item is based upon) fails because the COALESCE() expression is first seen by initialize_mergeclause_eclasses rather than process_equivalence. Fixing this requires passing the appropriate nullable_relids set to get_eclass_for_sort_expr, and it requires new code to compute that set for top-level expressions such as ORDER BY, GROUP BY, etc. We store the top-level nullable_relids in a new field in PlannerInfo to avoid computing it many times. In the back branches, I've added the new field at the end of the struct to minimize ABI breakage for planner plugins. There doesn't seem to be a good alternative to changing get_eclass_for_sort_expr's API signature, though. There probably aren't any third-party extensions calling that function directly; moreover, if there are, they probably need to think about what to pass for nullable_relids anyway. Back-patch to 9.2, like the previous patch in this area. 15 November 2013, 21:46:25 UTC
42f8e26 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:44 UTC
d147aed 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:19 UTC
449d5ac Tom Lane 11 November 2013, 21:36:27 UTC Fix failure with whole-row reference to a subquery. Simple oversight in commit 1cb108efb0e60d87e4adec38e7636b6e8efbeb57 --- recursively examining a subquery output column is only sane if the original Var refers to a single output column. Found by Kevin Grittner. 11 November 2013, 21:36:44 UTC
c6ec879 Magnus Hagander 11 November 2013, 13:34:06 UTC Don't abort pg_basebackup when receiving empty WAL block This can happen exactly at the switch of a logical WAL file (segment number ending in FE), when running pg_basebackup connected to a standby server, and would cause the backup to abort with the error message "streaming header too small". There is nothing wrong with an empty message, it's just unnecessary, and the rest of the code can handle the case of an empty message, so this patch just removes the error condition when the size is exactly zero. 11 November 2013, 13:34:06 UTC
9a45a65 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:11 UTC
f7171c7 Tom Lane 08 November 2013, 16:37:04 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:04 UTC
733e49e Tom Lane 08 November 2013, 13:59:49 UTC Fix subtly-wrong volatility checking in BeginCopyFrom(). contain_volatile_functions() is best applied to the output of expression_planner(), not its input, so that insertion of function default arguments and constant-folding have been done. (See comments at CheckMutability, for instance.) It's perhaps unlikely that anyone will notice a difference in practice, but still we should do it properly. In passing, change variable type from Node* to Expr* to reduce the net number of casts needed. Noted while perusing uses of contain_volatile_functions(). 08 November 2013, 13:59:49 UTC
64f5962 Tom Lane 07 November 2013, 21:33:25 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:25 UTC
8bd5a6a Tom Lane 07 November 2013, 19:41:43 UTC Prevent display of dropped columns in row constraint violation messages. ExecBuildSlotValueDescription() printed "null" for each dropped column in a row being complained of by ExecConstraints(). This has some sanity in terms of the underlying implementation, but is of course pretty surprising to users. To fix, we must pass the target relation's descriptor to ExecBuildSlotValueDescription(), because the slot descriptor it had been using doesn't get labeled with attisdropped markers. Per bug #8408 from Maxim Boguk. Back-patch to 9.2 where the feature of printing row values in NOT NULL and CHECK constraint violation messages was introduced. Michael Paquier and Tom Lane 07 November 2013, 19:41:43 UTC
aa8a2c3 Tom Lane 07 November 2013, 18:13:19 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:19 UTC
74aea2a Tom Lane 06 November 2013, 18:26:38 UTC Support default arguments and named-argument notation for window functions. These things didn't work because the planner omitted to do the necessary preprocessing of a WindowFunc's argument list. Add the few dozen lines of code needed to handle that. Although this sounds like a feature addition, it's really a bug fix because the default-argument case was likely to crash previously, due to lack of checking of the number of supplied arguments in the built-in window functions. It's not a security issue because there's no way for a non-superuser to create a window function definition with defaults that refers to a built-in C function, but nonetheless people might be annoyed that it crashes rather than producing a useful error message. So back-patch as far as the patch applies easily, which turns out to be 9.2. I'll put a band-aid in earlier versions as a separate patch. (Note that these features still don't work for aggregates, and fixing that case will be harder since we represent aggregate arg lists as target lists not bare expression lists. There's no crash risk though because CREATE AGGREGATE doesn't accept defaults, and we reject named-argument notation when parsing an aggregate call.) 06 November 2013, 18:26:38 UTC
599942c Tom Lane 06 November 2013, 02:58:16 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:16 UTC
85de126 Tom Lane 03 November 2013, 16:33:13 UTC Prevent memory leaks from accumulating across printtup() calls. Historically, printtup() has assumed that it could prevent memory leakage by pfree'ing the string result of each output function and manually managing detoasting of toasted values. This amounts to assuming that datatype output functions never leak any memory internally; an assumption we've already decided to be bogus elsewhere, for example in COPY OUT. range_out in particular is known to leak multiple kilobytes per call, as noted in bug #8573 from Godfried Vanluffelen. While we could go in and fix that leak, it wouldn't be very notationally convenient, and in any case there have been and undoubtedly will again be other leaks in other output functions. So what seems like the best solution is to run the output functions in a temporary memory context that can be reset after each row, as we're doing in COPY OUT. Some quick experimentation suggests this is actually a tad faster than the retail pfree's anyway. This patch fixes all the variants of printtup, except for debugtup() which is used in standalone mode. It doesn't seem worth worrying about query-lifespan leaks in standalone mode, and fixing that case would be a bit tedious since debugtup() doesn't currently have any startup or shutdown functions. While at it, remove manual detoast management from several other output-function call sites that had copied it from printtup(). This doesn't make a lot of difference right now, but in view of recent discussions about supporting "non-flattened" Datums, we're going to want that code gone eventually anyway. Back-patch to 9.2 where range_out was introduced. We might eventually decide to back-patch this further, but in the absence of known major leaks in older output functions, I'll refrain for now. 03 November 2013, 16:33:13 UTC
f2d6bdf 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:08 UTC
a1c3d54 Tom Lane 02 November 2013, 20:45:42 UTC Retry after buffer locking failure during SPGiST index creation. The original coding thought this case was impossible, but it can happen if the bgwriter or checkpointer processes decide to write out an index page while creation is still proceeding, leading to a bogus "unexpected spgdoinsert() failure" error. Problem reported by Jonathan S. Katz. Teodor Sigaev 02 November 2013, 20:45:57 UTC
2f2507e Tom Lane 01 November 2013, 20:09:57 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:09:57 UTC
2e21349 Tom Lane 01 November 2013, 16:13:26 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:26 UTC
a37f94a Tom Lane 29 October 2013, 00:49:32 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:32 UTC
9060cb9 Andrew Dunstan 28 October 2013, 15:45:50 UTC Work around NetBSD shell issue in pg_upgrade test script. The NetBSD shell apparently returns non-zero from an unset command if the variable is already unset. This matters when, as in pg_upgrade's test.sh, we are working under 'set -e'. To protect against this, we first set the PG variables to an empty string before unsetting them completely. Error found on buildfarm member coypu, solution from Rémi Zara. 28 October 2013, 15:55:57 UTC
4da24f1 Heikki Linnakangas 23 October 2013, 11:03:54 UTC Fix two bugs in setting the vm bit of empty pages. Use a critical section when setting the all-visible flag on an empty page, and WAL-logging it. log_newpage_buffer() contains an assertion that it must be called inside a critical section, and it's the right thing to do when modifying a buffer anyway. Also, the page should be marked dirty before calling log_newpage_buffer(), per the comment in log_newpage_buffer() and src/backend/access/transam/README. Patch by Andres Freund, in response to my report. Backpatch to 9.2, like the patch that introduced these bugs (a6370fd9). 23 October 2013, 11:25:50 UTC
b89cede 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:06 UTC
2a5496f 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
5fbed6b 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
7800229 Peter Eisentraut 08 October 2013, 03:16:13 UTC Stamp 9.2.5. 08 October 2013, 03:16:13 UTC
e2ccba0 Peter Eisentraut 08 October 2013, 02:42:26 UTC Revert "Document support for VPATH builds of extensions." This reverts commit 565beb41bdd73611ddb26165b7f6bb8b6157e49d. 08 October 2013, 02:42:26 UTC
7a80aaf Peter Eisentraut 08 October 2013, 02:37:26 UTC Revert "Backpatch pgxs vpath build and installation fixes (v2)" This reverts commit dd9abd3c995dbc4d32cfc97fde03fe3583e2717c. pending resolution of http://www.postgresql.org/message-id/1381193255.25702.4.camel@vanquo.pezone.net 08 October 2013, 02:37:26 UTC
df9ede9 Bruce Momjian 08 October 2013, 01:35:02 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:02 UTC
9037843 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:04:28 UTC
4dd5c31 Peter Eisentraut 07 October 2013, 20:17:51 UTC Translation updates 07 October 2013, 20:17:51 UTC
1f4cdf2 Kevin Grittner 07 October 2013, 19:15:24 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:15:24 UTC
565beb4 Andrew Dunstan 07 October 2013, 03:06:10 UTC Document support for VPATH builds of extensions. Cédric Villemain and me. 07 October 2013, 03:06:10 UTC
d565ece Peter Eisentraut 03 October 2013, 01:33:26 UTC doc: Correct psycopg URL 03 October 2013, 01:34:16 UTC
dd9abd3 Andrew Dunstan 30 September 2013, 14:36:01 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:36:01 UTC
fc7a38f 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:54:37 UTC
59d30d9 Andrew Dunstan 30 September 2013, 04:07:48 UTC Revert "Backpatch pgxs vpath build and installation fixes." This reverts commit cd453fef0bcfdc3c79c884e971cb84b88cb9d28d. 30 September 2013, 04:07:48 UTC
cd453fe Andrew Dunstan 29 September 2013, 21:32:13 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:32:13 UTC
e046194 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:38:55 UTC
db7e953 Heikki Linnakangas 25 September 2013, 13:02:00 UTC Plug memory leak in range_cmp function. B-tree operators are not allowed to leak memory into the current memory context. Range_cmp leaked detoasted copies of the arguments. That caused a quick out-of-memory error when creating an index on a range column. Reported by Marian Krucina, bug #8468. 25 September 2013, 13:05:52 UTC
769c36a Alvaro Herrera 24 September 2013, 21:19:14 UTC Fix pgindent comment breakage 24 September 2013, 21:21:11 UTC
c05e9ec 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:00 UTC
d707a8c 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:42:51 UTC
4392db8 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:17 UTC
e819308 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:13 UTC
7612553 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:13 UTC
1bb4b62 Jeff Davis 05 September 2013, 06:30:27 UTC Improve Range Types and Exclusion Constraints example. Make the examples self-contained to avoid confusion. Per bug report 8367 from KOIZUMI Satoru. 05 September 2013, 14:29:39 UTC
9ac5f63 Tom Lane 03 September 2013, 22:32:26 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:26 UTC
bc63ff2 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:34 UTC
7d0492f Andrew Dunstan 02 September 2013, 18:36:24 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:24 UTC
e912963 Andrew Dunstan 26 August 2013, 18:56:49 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:56:49 UTC
005f583 Tom Lane 24 August 2013, 19:14:24 UTC Account better for planning cost when choosing whether to use custom plans. The previous coding in plancache.c essentially used 10% of the estimated runtime as its cost estimate for planning. This can be pretty bogus, especially when the estimated runtime is very small, such as in a simple expression plan created by plpgsql, or a simple INSERT ... VALUES. While we don't have a really good handle on how planning time compares to runtime, it seems reasonable to use an estimate based on the number of relations referenced in the query, with a rather large multiplier. This patch uses 1000 * cpu_operator_cost * (nrelations + 1), so that even a trivial query will be charged 1000 * cpu_operator_cost for planning. This should address the problem reported by Marc Cousin and others that 9.2 and up prefer custom plans in cases where the planning time greatly exceeds what can be saved. 24 August 2013, 19:14:24 UTC
3979ff1 Magnus Hagander 24 August 2013, 15:11:31 UTC Don't crash when pg_xlog is empty and pg_basebackup -x is used The backup will not work (without a logarchive, and that's the whole point of -x) in this case, this patch just changes it to throw an error instead of crashing when this happens. Noticed and diagnosed by TAKATSUKA Haruka 24 August 2013, 15:14:09 UTC
bd5ab4b Tom Lane 23 August 2013, 21:31:00 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:00 UTC
b94c6c6 Peter Eisentraut 18 August 2013, 01:46:32 UTC libpq: Report strerror on pthread_mutex_lock() failure 18 August 2013, 01:52:24 UTC
cbb565f Tom Lane 03 August 2013, 16:39:54 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:40 UTC
0876787 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:00 UTC
1e8e324 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:42 UTC
9d7f66b 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:23:55 UTC
8505ebf Tom Lane 31 July 2013, 15:31:30 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:30 UTC
e73357c Fujii Masao 31 July 2013, 13:37:11 UTC Fix inaccurate description of tablespace. Currently we don't need to update the pg_tablespace catalog after redefining the symbolic links to the tablespaces because pg_tablespace.spclocation column was removed in PostgreSQL 9.2. Back patch to 9.2 where pg_tablespace.spclocation was removed. Ian Barwick, with minor change by me. 31 July 2013, 13:37:11 UTC
b3ddd10 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, 22:39:34 UTC
9822dc3 Tom Lane 29 July 2013, 14:42:44 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:44 UTC
8714465 Tom Lane 25 July 2013, 15:39:15 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:15 UTC
9f8254c 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:36 UTC
980c24e Alvaro Herrera 23 July 2013, 21:38:32 UTC Check for NULL result from strdup Per Coverity Scan 23 July 2013, 21:38:32 UTC
5fbc313 Tom Lane 23 July 2013, 20:23:08 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:08 UTC
c0977b4 Tom Lane 20 July 2013, 16:44:37 UTC Fix error handling in PLy_spi_execute_fetch_result(). If an error is thrown out of the datatype I/O functions called by this function, we need to do subtransaction cleanup, which the previous coding entirely failed to do. Fortunately, both existing callers of this function already have proper cleanup logic, so re-throwing the exception is enough. Also, postpone creation of the resultset tupdesc until after the I/O conversions are complete, so that we won't leak memory in TopMemoryContext when such an error happens. 20 July 2013, 16:45:02 UTC
e8ceb47 Robert Haas 19 July 2013, 14:23:12 UTC doc: Fix typos in conversion names. David Christensen 19 July 2013, 14:54:18 UTC
c9351a9 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:31 UTC
f1cb440 Tom Lane 19 July 2013, 01:22:47 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:47 UTC
cce5d68 Stephen Frost 17 July 2013, 14:50:39 UTC Use correct parameter name for view_option_value The documentation for ALTER VIEW had a minor copy-and-paste error in defining the parameters. Noticed when reviewing the WITH CHECK OPTION patch. Backpatch to 9.2 where this was first introduced. 17 July 2013, 14:53:38 UTC
a3957ac Stephen Frost 15 July 2013, 14:42:27 UTC Correct off-by-one when reading from pipe In pg_basebackup.c:reached_end_position(), we're reading from an internal pipe with our own background process but we're possibly reading more bytes than will actually fit into our buffer due to an off-by-one error. As we're reading from an internal pipe there's no real risk here, but it's good form to not depend on such convenient arrangements. Bug spotted by the Coverity scanner. Back-patch to 9.2 where this showed up. 15 July 2013, 14:48:08 UTC
back to top