aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Fix old visibility bug in HeapTupleSatisfiesDirtyAlvaro Herrera2013-08-02
| | | | | | | | | | | | | | | | | 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
* Improve handling of pthread_mutex_lock error caseStephen Frost2013-08-01
| | | | | | | | 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
* Add locking around SSL_context usage in libpqStephen Frost2013-08-01
| | | | | | | | | | | | | | | | | | | 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.
* Fix regexp_matches() handling of zero-length matches.Tom Lane2013-07-31
| | | | | | | | | | | 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.
* Restore REINDEX constraint validation.Noah Misch2013-07-30
| | | | | | | | | 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.
* Fix booltestsel() for case where we have NULL stats but not MCV stats.Tom Lane2013-07-24
| | | | | | | | | | | | 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.
* Check for NULL result from strdupAlvaro Herrera2013-07-23
| | | | Per Coverity Scan
* Change post-rewriter representation of dropped columns in joinaliasvars.Tom Lane2013-07-23
| | | | | | | | | | | | | | | | | | | | | 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.
* Fix error handling in PLy_spi_execute_fetch_result().Tom Lane2013-07-20
| | | | | | | | | | | 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.
* Initialize day of year value.Michael Meskes2013-07-19
| | | | | There are cases where the day of year value in struct tm is used, but it never got calculated. Problem found by Coverity scan.
* Fix regex match failures for backrefs combined with non-greedy quantifiers.Tom Lane2013-07-18
| | | | | | | | | | | | 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.
* Correct off-by-one when reading from pipeStephen Frost2013-07-15
| | | | | | | | | | | | | 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.
* Ensure 64bit arithmetic when calculating tapeSpaceStephen Frost2013-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix planning of parameterized appendrel paths with expensive join quals.Tom Lane2013-07-07
| | | | | | | | | | | | | | The code in set_append_rel_pathlist() for building parameterized paths for append relations (inheritance and UNION ALL combinations) supposed that the cheapest regular path for a child relation would still be cheapest when reparameterized. Which might not be the case, particularly if the added join conditions are expensive to compute, as in a recent example from Jeff Janes. Fix it to compare child path costs *after* reparameterizing. We can short-circuit that if the cheapest pre-existing path is already parameterized correctly, which seems likely to be true often enough to be worth checking for. Back-patch to 9.2 where parameterized paths were introduced.
* Fix include-guardMagnus Hagander2013-07-07
| | | | | | Looks like a cut/paste error in the original addition of the file. Andres Freund
* Also escape double quotes for ECPG's #line statement.Michael Meskes2013-07-06
|
* Applied patch by MauMau <maumau307@gmail.com> to escape filenames in #line ↵Michael Meskes2013-07-05
| | | | statements.
* Silence compiler warning in assertion-enabled builds.Heikki Linnakangas2013-07-02
| | | | | | | | | With -Wtype-limits, gcc correctly points out that size_t can never be < 0. Backpatch to 9.3 and 9.2. It's been like this forever, but in <= 9.1 you got a lot other warnings with -Wtype-limits anyway (at least with my version of gcc). Andres Freund
* Mark index-constraint comments with correct dependency in pg_dump.Tom Lane2013-06-27
| | | | | | | | | | | | | | | | | 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
* Expect EWOULDBLOCK from a non-blocking connect() call only on Windows.Tom Lane2013-06-27
| | | | | | | | | | | | | | | | | | | | | | | 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
* Properly dump dropped foreign table cols in binary-upgrade mode.Andrew Dunstan2013-06-25
| | | | | | | | | 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.
* Support clean switchover.Fujii Masao2013-06-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Ensure no xid gaps during Hot Standby startupSimon Riggs2013-06-23
| | | | | | | | | 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
* Fix the create_index regression test for Danish collation.Kevin Grittner2013-06-19
| | | | | | | | | | In Danish collations, there are letter combinations which sort higher than 'Z'. A test for values > 'WA' was picking up rows where the value started with 'AA', causing the test to fail. Backpatch to 9.2, where the failing test was added. Per report from Svenne Krap and analysis by Jeff Janes
* Fix pg_restore -l with the directory archive to display the correct format name.Fujii Masao2013-06-16
| | | | Back-patch to 9.1 where the directory archive was introduced.
* Avoid deadlocks during insertion into SP-GiST indexes.Tom Lane2013-06-14
| | | | | | | | | | | | | SP-GiST's original scheme for avoiding deadlocks during concurrent index insertions doesn't work, as per report from Hailong Li, and there isn't any evident way to make it work completely. We could possibly lock individual inner tuples instead of their whole pages, but preliminary experimentation suggests that the performance penalty would be huge. Instead, if we fail to get a buffer lock while descending the tree, just restart the tree descent altogether. We keep the old tuple positioning rules, though, in hopes of reducing the number of cases where this can happen. Teodor Sigaev, somewhat edited by Tom Lane
* Only install a portal's ResourceOwner if it actually has one.Tom Lane2013-06-13
| | | | | | | | | | | | | | | | | | | | | 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.
* Fix cache flush hazard in cache_record_field_properties().Tom Lane2013-06-11
| | | | | | | | | | | | 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.
* Fix ordering of obj id for Rules and EventTriggers in pg_dump.Joe Conway2013-06-09
| | | | | | | | | | 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.
* Remove unnecessary restrictions about RowExprs in transformAExprIn().Tom Lane2013-06-09
| | | | | | | | | | | | | | | | | | 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
* Remove ALTER DEFAULT PRIVILEGES' requirement of schema CREATE permissions.Tom Lane2013-06-09
| | | | | | | | 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.
* Remove fixed limit on the number of concurrent AllocateFile() requests.Tom Lane2013-06-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Don't downcase non-ascii identifier chars in multi-byte encodings.Andrew Dunstan2013-06-08
| | | | | | | | | | | | | Long-standing code has called tolower() on identifier character bytes with the high bit set. This is clearly an error and produces junk output when the encoding is multi-byte. This patch therefore restricts this activity to cases where there is a character with the high bit set AND the encoding is single-byte. There have been numerous gripes about this, most recently from Martin Schäfer. Backpatch to all live releases.
* Fix typo in comment.Heikki Linnakangas2013-06-06
|
* Ensure that XLOG_HEAP2_VISIBLE always targets an initialized page.Robert Haas2013-06-06
| | | | Andres Freund
* Backport log_newpage_buffer.Robert Haas2013-06-06
| | | | | Andres' fix for XLOG_HEAP2_VISIBLE on unitialized pages requires this.
* Prevent pushing down WHERE clauses into unsafe UNION/INTERSECT nests.Tom Lane2013-06-05
| | | | | | | | | | | | | | | | | | | | | | | | The planner is aware that it mustn't push down upper-level quals into subqueries if the quals reference subquery output columns that contain set-returning functions or volatile functions, or are non-DISTINCT outputs of a DISTINCT ON subquery. However, it missed making this check when there were one or more levels of UNION or INTERSECT above the dangerous expression. This could lead to "set-valued function called in context that cannot accept a set" errors, as seen in bug #8213 from Eric Soroos, or to silently wrong answers in the other cases. To fix, refactor the checks so that we make the column-is-unsafe checks during subquery_is_pushdown_safe(), which already has to recursively inspect all arms of a set-operation tree. This makes qual_is_pushdown_safe() considerably simpler, at the cost that we will spend some cycles checking output columns that possibly aren't referenced in any upper qual. But the cases where this code gets executed at all are already nontrivial queries, so it's unlikely anybody will notice any slowdown of planning. This has been broken since commit 05f916e6add9726bf4ee046e4060c1b03c9961f2, which makes the bug over ten years old. A bit surprising nobody noticed it before now.
* Put analyze_keyword back in explain_option_name production.Tom Lane2013-06-05
| | | | | | | | | | | | | | | | | In commit 2c92edad48796119c83d7dbe6c33425d1924626d, I broke "EXPLAIN (ANALYZE)" syntax, because I mistakenly thought that ANALYZE/ANALYSE were only partially reserved and thus would be included in NonReservedWord; but actually they're fully reserved so they still need to be called out here. A nicer solution would be to demote these words to type_func_name_keyword status (they can't be less than that because of "VACUUM [ANALYZE] ColId"). While that works fine so far as the core grammar is concerned, it breaks ECPG's grammar for reasons I don't have time to isolate at the moment. So do this for the time being. Per report from Kevin Grittner. Back-patch to 9.0, like the previous commit.
* Provide better message when CREATE EXTENSION can't find a target schema.Tom Lane2013-06-04
| | | | | | | | | | | | | | The new message (and SQLSTATE) matches the corresponding error cases in namespace.c. This was thought to be a "can't happen" case when extension.c was written, so we didn't think hard about how to report it. But it definitely can happen in 9.2 and later, since we no longer require search_path to contain any valid schema names. It's probably also possible in 9.1 if search_path came from a noninteractive source. So, back-patch to all releases containing this code. Per report from Sean Chittenden, though this isn't exactly his patch.
* Add ARM64 (aarch64) support to s_lock.h.Tom Lane2013-06-04
| | | | | | | | | | | | Use the same gcc atomic functions as we do on newer ARM chips. (Basically this is a copy and paste of the __arm__ code block, but omitting the SWPB option since that definitely won't work.) Back-patch to 9.2. The patch would work further back, but we'd also need to update config.guess/config.sub in older branches to make them build out-of-the-box, and there hasn't been demand for it. Mark Salter
* Fix memory leak in LogStandbySnapshot().Tom Lane2013-06-04
| | | | | | | | | | | | | | The array allocated by GetRunningTransactionLocks() needs to be pfree'd when we're done with it. Otherwise we leak some memory during each checkpoint, if wal_level = hot_standby. This manifests as memory bloat in the checkpointer process, or in bgwriter in versions before we made the checkpointer separate. Reported and fixed by Naoya Anzai. Back-patch to 9.0 where the issue was introduced. In passing, improve comments for GetRunningTransactionLocks(), and add an Assert that we didn't overrun the palloc'd array.
* Add semicolons to eval'd strings to hide a minor Perl behavioral change.Tom Lane2013-06-03
| | | | | | | | | | | | "eval q{foo}" used to complain that the error was on line 2 of the eval'd string, because eval internally tacked on "\n;" so that the end of the erroneous command was indeed on line 2. But as of Perl 5.18 it more sanely says that the error is on line 1. To avoid Perl-version-dependent regression test results, use "eval q{foo;}" instead in the two places where this matters. Per buildfarm. Since people might try to use newer Perl versions with older PG releases, back-patch as far as 9.0 where these test cases were added.
* Allow type_func_name_keywords in some places where they weren't before.Tom Lane2013-06-02
| | | | | | | | | | | | | | | This change makes type_func_name_keywords less reserved than they were before, by allowing them for role names, language names, EXPLAIN and COPY options, and SET values for GUCs; which are all places where few if any actual keywords could appear instead, so no new ambiguities are introduced. The main driver for this change is to allow "COPY ... (FORMAT BINARY)" to work without quoting the word "binary". That is an inconsistency that has been complained of repeatedly over the years (at least by Pavel Golub, Kurt Lidl, and Simon Riggs); but we hadn't thought of any non-ugly solution until now. Back-patch to 9.0 where the COPY (FORMAT BINARY) syntax was introduced.
* Fix typo in comment.Robert Haas2013-05-23
| | | | Pavan Deolasee
* Print line number correctly in COPY.Heikki Linnakangas2013-05-23
| | | | | | | | | | When COPY uses the multi-insert method to insert a batch of tuples into the heap at a time, incorrect line number was printed if something went wrong in inserting the index tuples (primary key failure, for exampl), or processing after row triggers. Fixes bug #8173 reported by Lloyd Albin. Backpatch to 9.2, where the multi- insert code was added.
* Fix fd.c to preserve errno where needed.Tom Lane2013-05-16
| | | | | | | | | | | | | | | | | PathNameOpenFile failed to ensure that the correct value of errno was returned to its caller after a failure (because it incorrectly supposed that free() can never change errno). In some cases this would result in a user-visible failure because an expected ENOENT errno was replaced with something else. Bogus EINVAL failures have been observed on OS X, for example. There were also a couple of places that could mangle an important value of errno if FDDEBUG was defined. While the usefulness of that debug support is highly debatable, we might as well make it safe to use, so add errno save/restore logic to the DO_DB macro. Per bug #8167 from Nelson Minar, diagnosed by RhodiumToad. Back-patch to all supported branches.
* Fix handling of OID wraparound while in standalone mode.Tom Lane2013-05-13
| | | | | | | | | | | If OID wraparound should occur while in standalone mode (unlikely but possible), we want to advance the counter to FirstNormalObjectId not FirstBootstrapObjectId. Otherwise, user objects might be created with OIDs in the system-reserved range. That isn't immediately harmful but it poses a risk of conflicts during future pg_upgrade operations. Noted by Andres Freund. Back-patch to all supported branches, since all of them are supported sources for pg_upgrade operations.
* Guard against input_rows == 0 in estimate_num_groups().Tom Lane2013-05-10
| | | | | | | | | | | | | | | This case doesn't normally happen, because the planner usually clamps all row estimates to at least one row; but I found that it can arise when dealing with relations excluded by constraints. Without a defense, estimate_num_groups() can return zero, which leads to divisions by zero inside the planner as well as assertion failures in the executor. An alternative fix would be to change set_dummy_rel_pathlist() to make the size estimate for a dummy relation 1 row instead of 0, but that seemed pretty ugly; and probably someday we'll want to drop the convention that the minimum rowcount estimate is 1 row. Back-patch to 8.4, as the problem can be demonstrated that far back.
* Fix management of fn_extra caching during repeated GiST index scans.Tom Lane2013-05-09
| | | | | | | | | | | | | | Commit d22a09dc70f9830fa78c1cd1a3a453e4e473d354 introduced official support for GiST consistentFns that want to cache data using the FmgrInfo fn_extra pointer: the idea was to preserve the cached values across gistrescan(), whereas formerly they'd been leaked. However, there was an oversight in that, namely that multiple scan keys might reference the same column's consistentFn; the code would result in propagating the same cache value into multiple scan keys, resulting in crashes or wrong answers. Use a separate array instead to ensure that each scan key keeps its own state. Per bug #8143 from Joel Roller. Back-patch to 9.2 where the bug was introduced.
* Revert "Fix permission tests for views/tables proven empty by constraint ↵Tom Lane2013-05-08
| | | | | | | | | | exclusion." This reverts commit 15b0421002624919c62ae3c6574af2a8452bf6c4. Per complaint from Robert Haas, that patch caused crashes on appendrel cases, and it didn't fix all forms of the problem anyway. Consensus is we'll leave this problem alone in the back branches, at least for now.