- 27 11月, 2012 1 次提交
-
-
由 Tom Lane 提交于
In a query such as "SELECT DISTINCT min(x) FROM tab", the DISTINCT is pretty useless (there being only one output row), but nonetheless it shouldn't fail. But it could fail if "tab" is an inheritance parent, because planagg.c's code for fixing up equivalence classes after making the index-optimized MIN/MAX transformation wasn't prepared to find child-table versions of the aggregate expression. The least ugly fix seems to be to add an option to mutate_eclass_expressions() to skip child-table equivalence class members, which aren't used anymore at this stage of planning so it's not really necessary to fix them. Since child members are ignored in many cases already, it seems plausible for mutate_eclass_expressions() to have an option to ignore them too. Per bug #7703 from Maxim Boguk. Back-patch to 9.1. Although the same code exists before that, it cannot encounter child-table aggregates AFAICS, because the index optimization transformation cannot succeed on inheritance trees before 9.1 (for lack of MergeAppend).
-
- 20 11月, 2012 1 次提交
-
-
由 Tom Lane 提交于
Some platforms throw an exception for this division, rather than returning a necessarily-overflowed result. Since we were testing for overflow after the fact, an exception isn't nice. We can avoid the problem by treating division by -1 as negation. Add some regression tests so that we'll find out if any compilers try to optimize away the overflow check conditions. This ought to be back-patched, but I'm going to see what the buildfarm reports about the regression tests first. Per discussion with Xi Wang, though this is different from the patch he submitted.
-
- 06 11月, 2012 1 次提交
-
-
由 Tom Lane 提交于
This case got broken in 8.4 by the addition of an error check that complains if ALTER TABLE ONLY is used on a table that has children. We do use ONLY for this situation, but it's okay because the necessary recursion occurs at a higher level. So we need to have a separate flag to suppress recursion without making the error check. Reported and patched by Pavan Deolasee, with some editorial adjustments by me. Back-patch to 8.4, since this is a regression of functionality that worked in earlier branches.
-
- 02 11月, 2012 1 次提交
-
- 27 10月, 2012 1 次提交
-
-
由 Kevin Grittner 提交于
This prevents surprising behavior when a FOR EACH ROW trigger BEFORE UPDATE or BEFORE DELETE directly or indirectly updates or deletes the the old row. Prior to this patch the requested action on the row could be silently ignored while all triggered actions based on the occurence of the requested action could be committed. One example of how this could happen is if the BEFORE DELETE trigger for a "parent" row deleted "children" which had trigger functions to update summary or status data on the parent. This also prevents similar surprising problems if the query has a volatile function which updates a target row while it is already being updated. There are related issues present in FOR UPDATE cursors and READ COMMITTED queries which are not handled by this patch. These issues need further evalution to determine what change, if any, is needed. Where the new error messages are generated, in most cases the best fix will be to move code from the BEFORE trigger to an AFTER trigger. Where this is not feasible, the trigger can avoid the error by re-issuing the triggering statement and returning NULL. Documentation changes will be submitted in a separate patch. Kevin Grittner and Tom Lane with input from Florian Pflug and Robert Haas, based on problems encountered during conversion of Wisconsin Circuit Court trigger logic to plpgsql triggers.
-
- 25 10月, 2012 1 次提交
-
-
由 Tom Lane 提交于
Views should not have any pg_attribute entries for system columns. However, we forgot to remove such entries when converting a table to a view. This could lead to crashes later on, if someone attempted to reference such a column, as reported by Kohei KaiGai. Patch in HEAD only. This bug has been there forever, but in the back branches we will have to defend against existing mis-converted views, so it doesn't seem worthwhile to change the conversion code too.
-
- 19 10月, 2012 2 次提交
-
-
由 Simon Riggs 提交于
for recent concurrent changes. Abhijit Menon-Sen
-
由 Tom Lane 提交于
If a potential equivalence clause references a variable from the nullable side of an outer join, the planner needs to take care that derived clauses are not pushed to below the outer join; else they may use the wrong value for the variable. (The problem arises only with non-strict clauses, since if an upper clause can be proven strict then the outer join will get simplified to a plain join.) The planner attempted to prevent this type of error by checking that potential equivalence clauses aren't outerjoin-delayed as a whole, but actually we have to check each side separately, since the two sides of the clause will get moved around separately if it's treated as an equivalence. Bugs of this type can be demonstrated as far back as 7.4, even though releases before 8.3 had only a very ad-hoc notion of equivalence clauses. In addition, we neglected to account for the possibility that such clauses might have nonempty nullable_relids even when not outerjoin-delayed; so the equivalence-class machinery lacked logic to compute correct nullable_relids values for clauses it constructs. This oversight was harmless before 9.2 because we were only using RestrictInfo.nullable_relids for OR clauses; but as of 9.2 it could result in pushing constructed equivalence clauses to incorrect places. (This accounts for bug #7604 from Bill MacArthur.) Fix the first problem by adding a new test check_equivalence_delay() in distribute_qual_to_rels, and fix the second one by adding code in equivclass.c and called functions to set correct nullable_relids for generated clauses. Although I believe the second part of this is not currently necessary before 9.2, I chose to back-patch it anyway, partly to keep the logic similar across branches and partly because it seems possible we might find other reasons why we need valid values of nullable_relids in the older branches. Add regression tests illustrating these problems. In 9.0 and up, also add test cases checking that we can push constants through outer joins, since we've broken that optimization before and I nearly broke it again with an overly simplistic patch for this problem.
-
- 18 10月, 2012 2 次提交
-
-
由 Simon Riggs 提交于
-
由 Simon Riggs 提交于
Backpatch to 9.2 to ensure bugs are fixed. Abhijit Menon-Sen
-
- 16 10月, 2012 1 次提交
-
-
由 Tom Lane 提交于
... because the latter plays games with the privileges for language SQL. It looks like running alter_generic in parallel with "misc" is OK though. Also, adjust serial_schedule to maintain the same test ordering (up to parallelism) as parallel_schedule.
-
- 13 10月, 2012 1 次提交
-
- 12 10月, 2012 1 次提交
-
-
由 Tom Lane 提交于
When hashing a subplan like "WHERE (a, b) NOT IN (SELECT x, y FROM ...)", findPartialMatch() attempted to match rows using the hashtable's internal equality operators, which of course are for x and y's datatypes. What we need to use are the potentially cross-type operators for a=x, b=y, etc. Failure to do that leads to wrong answers or even crashes. The scope for problems is limited to cases where we have different types with compatible hash functions (else we'd not be using a hashed subplan), but for example int4 vs int8 can cause the problem. Per bug #7597 from Bo Jensen. This has been wrong since the hashed-subplan code was written, so patch all the way back.
-
- 11 10月, 2012 1 次提交
-
-
由 Peter Eisentraut 提交于
Numerous flex and bison make rules have appeared in the source tree over time, and they are all virtually identical, so we can replace them by pattern rules with some variables for customization. Users of pgxs will also be able to benefit from this.
-
- 09 10月, 2012 2 次提交
-
-
由 Tom Lane 提交于
lo_export returns -1, not zero, on failure.
-
由 Tom Lane 提交于
Fix broken-on-bigendian-machines byte-swapping functions, add missed update of alternate regression expected file, improve error reporting, remove some unnecessary code, sync testlo64.c with current testlo.c (it seems to have been cloned from a very old copy of that), assorted cosmetic improvements.
-
- 07 10月, 2012 1 次提交
-
-
由 Tatsuo Ishii 提交于
4TB large objects (standard 8KB BLCKSZ case). For this purpose new libpq API lo_lseek64, lo_tell64 and lo_truncate64 are added. Also corresponding new backend functions lo_lseek64, lo_tell64 and lo_truncate64 are added. inv_api.c is changed to handle 64-bit offsets. Patch contributed by Nozomi Anzai (backend side) and Yugo Nagata (frontend side, docs, regression tests and example program). Reviewed by Kohei Kaigai. Committed by Tatsuo Ishii with minor editings.
-
- 05 10月, 2012 1 次提交
-
-
由 Tom Lane 提交于
The previous coding of the YYLLOC_DEFAULT macro behaved strangely for empty productions, assigning the previous nonterminal's location as the parse location of the result. The usefulness of that was (at best) debatable already, but the real problem is that in list-generating nonterminals like OptFooList: /* EMPTY */ { ... } | OptFooList Foo { ... } ; the initially-identified location would get copied up, so that even a nonempty list would be given a bogus parse location. Document how to work around that, and do so for OptSchemaEltList, so that the error condition just added for CREATE SCHEMA IF NOT EXISTS produces a sane error cursor. So far as I can tell, there are currently no other cases where the situation arises, so we don't need other instances of this coding yet.
-
- 04 10月, 2012 1 次提交
-
-
由 Tom Lane 提交于
Per discussion, schema-element subcommands are not allowed together with this option, since it's not very obvious what should happen to the element objects. Fabrízio de Royes Mello
-
- 01 10月, 2012 1 次提交
-
-
由 Alvaro Herrera 提交于
The error messages they generate are not portable enough. Also, since the only point of the alter_generic_1 expected file was to cover platforms with no collation support, it's now useless, so remove it.
-
- 29 9月, 2012 2 次提交
-
-
由 Alvaro Herrera 提交于
The original only expected file failed to consider machines without non-default collation support. Per buildfarm. Also, move the test to another parallel group; the one it was originally put in is already full according to comments in the schedule file. Per note from Tom Lane.
-
由 Alvaro Herrera 提交于
This makes refactoring of parts of the ALTER command safe(r) because we ensure no change in functionality. Author: KaiGai Kohei
-
- 23 9月, 2012 2 次提交
-
-
由 Tom Lane 提交于
Produce a NOTICE when the label already exists, for consistency with other CREATE IF NOT EXISTS commands. Also, fix the code so it produces something more user-friendly than an index violation when the label already exists. This not incidentally enables making a regression test that the previous patch didn't make for fear of exposing an unpredictable OID in the results. Also some wordsmithing on the documentation.
-
由 Andrew Dunstan 提交于
If the label is already in the enum the statement becomes a no-op. This will reduce the pain that comes from our not allowing this operation inside a transaction block. Andrew Dunstan, reviewed by Tom Lane and Magnus Hagander.
-
- 22 9月, 2012 1 次提交
-
-
由 Tom Lane 提交于
The previous scheme had bugs in some corner cases involving tables that had been renamed since a view was made. This could result in dumped views that failed to reload or reloaded incorrectly, as seen in bug #7553 from Lloyd Albin, as well as in some pgsql-hackers discussion back in January. Also, its behavior for printing EXPLAIN plans was sometimes confusing because of willingness to use the same alias for multiple RTEs (it was Ashutosh Bapat's complaint about that aspect that started the January thread). To fix, ensure that each RTE in the query has a unique unqualified alias, by modifying the alias if necessary (we add "_" and digits as needed to create a non-conflicting name). Then we can just print its variables with that alias, avoiding the confusing and bug-prone scheme of sometimes schema-qualifying variable names. In EXPLAIN, it proves to be expedient to take the further step of only assigning such aliases to RTEs that are actually referenced in the query, since the planner has a habit of generating extra RTEs with the same alias in situations such as inheritance-tree expansion. Although this fixes a bug of very long standing, I'm hesitant to back-patch such a noticeable behavioral change. My experiments while creating a regression test convinced me that actually incorrect output (as opposed to confusing output) occurs only in very narrow cases, which is backed up by the lack of previous complaints from the field. So we may be better off living with it in released branches; and in any case it'd be smart to let this ripen awhile in HEAD before we consider back-patching it.
-
- 19 9月, 2012 1 次提交
-
-
由 Tom Lane 提交于
In commit 9e8da0f7, I improved btree to handle ScalarArrayOpExpr quals natively, so that constructs like "indexedcol IN (list)" could be supported by index-only scans. Using such a qual results in multiple scans of the index, under-the-hood. I went to some lengths to ensure that this still produces rows in index order ... but I failed to recognize that if a higher-order index column is lacking an equality constraint, rescans can produce out-of-order data from that column. Tweak the planner to not expect sorted output in that case. Per trouble report from Robert McGehee.
-
- 17 9月, 2012 1 次提交
-
-
由 Tom Lane 提交于
Some experimentation with examples similar to bug #7539 has convinced me that indxpath.c's original implementation of parameterized-path generation was several bricks shy of a load. In general, if we are relying on a particular outer rel or set of outer rels for a parameterized path, the path should use every indexable join clause that's available from that rel or rels. Any join clauses that get left out of the indexqual will end up getting applied as plain filter quals (qpquals), and that's generally a significant loser compared to having the index AM enforce them. (This is particularly true with btree, which can skip the index scan entirely if it can see that the given indexquals are mutually contradictory.) The original heuristics failed to ensure this, though, and were overly complicated anyway. Rewrite to make the code explicitly identify each useful set of outer rels and then select all applicable join clauses for each one. The one plan that changes in the regression tests is in fact for the better according to the planner's cost estimates. (Note: this is not a correctness issue but just a matter of plan quality. I don't yet know what is going on in bug #7539, but I don't expect this change to fix that.)
-
- 16 9月, 2012 1 次提交
-
-
由 Tom Lane 提交于
Looks like the correct size of DOS-ified tenk.data is 680800 not 680801. (I got the latter from a version of unix2dos that appends a trailing ^Z, which evidently is not git's practice.)
-
- 15 9月, 2012 1 次提交
-
-
由 Tom Lane 提交于
The idea here is to provide a more easily diagnosable failure diff when the problem is that tenk.data has been DOS-ified, as I believe to be happening currently on buildfarm member hamerkop. Per suggestion from Magnus Hagander. Also, sync output/largeobject_1.source with current regression test. Failure to do that in commit 3a0e4d36 turns out to be the real reason that hamerkop has been complaining.
-
- 13 9月, 2012 1 次提交
-
-
由 Tom Lane 提交于
In commit 1bc16a94 I added a minor optimization to drop the component variables of a GROUP BY expression from the target list computed at the aggregation level of a query, if those Vars weren't referenced elsewhere in the tlist. However, I overlooked that the window-function planning code would deconstruct such expressions and thus need to have access to their component variables. Fix it to not do that. While at it, I removed the distinction between volatile and nonvolatile window partition/order expressions: the code now computes all of them at the aggregation level. This saves a relatively expensive check for volatility, and it's unclear that the resulting plan isn't better anyway. Per bug #7535 from Louis-David Mitterrand. Back-patch to 9.2.
-
- 06 9月, 2012 1 次提交
-
-
由 Tom Lane 提交于
The planner previously assumed that parameter Vars having the same absolute query level, varno, and varattno could safely be assigned the same runtime PARAM_EXEC slot, even though they might be different Vars appearing in different subqueries. This was (probably) safe before the introduction of CTEs, but the lazy-evalution mechanism used for CTEs means that a CTE can be executed during execution of some other subquery, causing the lifespan of Params at the same syntactic nesting level as the CTE to overlap with use of the same slots inside the CTE. In 9.1 we created additional hazards by using the same parameter-assignment technology for nestloop inner scan parameters, but it was broken before that, as illustrated by the added regression test. To fix, restructure the planner's management of PlannerParamItems so that items having different semantic lifespans are kept rigorously separated. This will probably result in complex queries using more runtime PARAM_EXEC slots than before, but the slots are cheap enough that this hardly matters. Also, stop generating PlannerParamItems containing Params for subquery outputs: all we really need to do is reserve the PARAM_EXEC slot number, and that now only takes incrementing a counter. The planning code is simpler and probably faster than before, as well as being more correct. Per report from Vik Reykja. These changes will mostly also need to be made in the back branches, but I'm going to hold off on that until after 9.2.0 wraps.
-
- 05 9月, 2012 2 次提交
-
-
由 Kevin Grittner 提交于
Serializable Snapshot Isolation used for serializable transactions depends on acquiring SIRead locks on all heap relation tuples which are used to generate the query result, so that a later delete or update of any of the tuples can flag a read-write conflict between transactions. This is normally handled in heapam.c, with tuple level locking. Since an index-only scan avoids heap access in many cases, building the result from the index tuple, the necessary predicate locks were not being acquired for all tuples in an index-only scan. To prevent problems with tuple IDs which are vacuumed and re-used while the transaction still matters, the xmin of the tuple is part of the tag for the tuple lock. Since xmin is not available to the index-only scan for result rows generated from the index tuples, it is not possible to acquire a tuple-level predicate lock in such cases, in spite of having the tid. If we went to the heap to get the xmin value, it would no longer be an index-only scan. Rather than prohibit index-only scans under serializable transaction isolation, we acquire an SIRead lock on the page containing the tuple, when it was not necessary to visit the heap for other reasons. Backpatch to 9.2. Kevin Grittner and Tom Lane
-
由 Kevin Grittner 提交于
Each setup block is run as a single PQexec submission, and some statements such as VACUUM cannot be combined with others in such a block. Backpatch to 9.2. Kevin Grittner and Tom Lane
-
- 02 9月, 2012 2 次提交
-
-
由 Tom Lane 提交于
We can detect whether the planner top level is going to care at all about cheap startup cost (it will only do so if query_planner's tuple_fraction argument is greater than zero). If it isn't, we might as well discard paths immediately whose only advantage over others is cheap startup cost. This turns out to get rid of quite a lot of paths in complex queries --- I saw planner runtime reduction of more than a third on one large query. Since add_path isn't currently passed the PlannerInfo "root", the easiest way to tell it whether to do this was to add a bool flag to RelOptInfo. That's a bit redundant, since all relations in a given query level will have the same setting. But in the future it's possible that we'd refine the control decision to work on a per-relation basis, so this seems like a good arrangement anyway. Per my suggestion of a few months ago.
-
由 Tom Lane 提交于
If a PlaceHolderVar contains a pulled-up LATERAL reference, its minimum possible evaluation level might be higher in the join tree than its original syntactic location. That in turn affects the ph_needed level for any contained PlaceHolderVars (that is, those PHVs had better propagate up the join tree at least to the evaluation level of the outer PHV). We got this mostly right, but mark_placeholder_maybe_needed() failed to account for the effect, and in consequence could leave the inner PHVs with ph_may_need less than what their ultimate ph_needed value will be. That's bad because it could lead to failure to select a join order that will allow evaluation of the inner PHV at a valid location. Fix that, and add an Assert that checks that we don't ever set ph_needed to more than ph_may_need.
-
- 01 9月, 2012 1 次提交
-
-
由 Tom Lane 提交于
I had thought this case worked already, but perhaps I didn't re-test it after adding extract_lateral_references() ...
-
- 31 8月, 2012 1 次提交
-
-
由 Tom Lane 提交于
push_child_plan/pop_child_plan didn't bother to adjust the "ancestors" list of parent plan nodes when descending to a child plan node. I think this was okay when it was written, but it's not okay in the presence of LATERAL references, since a subplan node could easily be returning a LATERAL value back up to the same nestloop node that provides the value. Per changed regression test results, the omission led to failure to interpret Param nodes that have perfectly good interpretations.
-
- 30 8月, 2012 1 次提交
-
-
由 Tom Lane 提交于
In the initial cut at LATERAL, I kept the rule that cheapest_total_path was always unparameterized, which meant it had to be NULL if the relation has no unparameterized paths. It turns out to work much more nicely if we always have *some* path nominated as cheapest-total for each relation. In particular, let's still say it's the cheapest unparameterized path if there is one; if not, take the cheapest-total-cost path among those of the minimum available parameterization. (The first rule is actually a special case of the second.) This allows reversion of some temporary lobotomizations I'd put in place. In particular, the planner can now consider hash and merge joins for joins below a parameter-supplying nestloop, even if there aren't any unparameterized paths available. This should bring planning of LATERAL-containing queries to the same level as queries not using that feature. Along the way, simplify management of parameterized paths in add_path() and friends. In the original coding for parameterized paths in 9.2, I tried to minimize the logic changes in add_path(), so it just treated parameterization as yet another dimension of comparison for paths. We later made it ignore pathkeys (sort ordering) of parameterized paths, on the grounds that ordering isn't a useful property for the path on the inside of a nestloop, so we might as well get rid of useless parameterized paths as quickly as possible. But we didn't take that reasoning as far as we should have. Startup cost isn't a useful property inside a nestloop either, so add_path() ought to discount startup cost of parameterized paths as well. Having done that, the secondary sorting I'd implemented (in add_parameterized_path) is no longer needed --- any parameterized path that survives add_path() at all is worth considering at higher levels. So this should be a bit faster as well as simpler.
-
- 28 8月, 2012 1 次提交
-
- 27 8月, 2012 1 次提交
-
-
由 Tom Lane 提交于
This patch takes care of a number of problems having to do with failure to choose valid join orders and incorrect handling of lateral references pulled up from subqueries. Notable changes: * Add a LateralJoinInfo data structure similar to SpecialJoinInfo, to represent join ordering constraints created by lateral references. (I first considered extending the SpecialJoinInfo structure, but the semantics are different enough that a separate data structure seems better.) Extend join_is_legal() and related functions to prevent trying to form unworkable joins, and to ensure that we will consider joins that satisfy lateral references even if the joins would be clauseless. * Fill in the infrastructure needed for the last few types of relation scan paths to support parameterization. We'd have wanted this eventually anyway, but it is necessary now because a relation that gets pulled up out of a UNION ALL subquery may acquire a reltargetlist containing lateral references, meaning that its paths *have* to be parameterized whether or not we have any code that can push join quals down into the scan. * Compute data about lateral references early in query_planner(), and save in RelOptInfo nodes, to avoid repetitive calculations later. * Assorted corner-case bug fixes. There's probably still some bugs left, but this is a lot closer to being real than it was before.
-