- 29 8月, 2013 2 次提交
-
-
由 Robert Haas 提交于
Using the infrastructure provided by this patch, it's possible either to wait for the startup of a dynamically-registered background worker, or to poll the status of such a worker without waiting. In either case, the current PID of the worker process can also be obtained. As usual, worker_spi is updated to demonstrate the new functionality. Patch by me. Review by Andres Freund.
-
由 Robert Haas 提交于
As noted by Tom Lane, commit 813fb031 was overly optimistic about how safe it is to concurrently change enumsortorder values under MVCC catalog scan semantics. Restore some of the previous text, with hopefully-correct adjustments for the new state of play.
-
- 28 8月, 2013 3 次提交
-
-
由 Heikki Linnakangas 提交于
We already did this for -t (--table) in 9.3, but missed the other similar options. For consistency, allow all of them to be specified multiple times. Unfortunately it's too late to sneak this into 9.3, so commit to master only.
-
由 Alvaro Herrera 提交于
Andres Freund; bug detected by valgrind
-
由 Alvaro Herrera 提交于
-
- 27 8月, 2013 1 次提交
-
-
由 Robert Haas 提交于
Christophe Pettus
-
- 25 8月, 2013 1 次提交
-
-
由 Tom Lane 提交于
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 8月, 2013 2 次提交
-
-
由 Magnus Hagander 提交于
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
-
由 Tom Lane 提交于
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.
-
- 22 8月, 2013 1 次提交
-
-
由 Tom Lane 提交于
We should account for the per-group hashtable entry overhead when considering whether to use a hash aggregate to implement DISTINCT. The comparable logic in choose_hashed_grouping() gets this right, but I think I omitted it here in the mistaken belief that there would be no overhead if there were no aggregate functions to be evaluated. This can result in more than 2X underestimate of the hash table size, if the tuples being aggregated aren't very wide. Per report from Tomas Vondra. This bug is of long standing, but per discussion we'll only back-patch into 9.3. Changing the estimation behavior in stable branches seems to carry too much risk of destabilizing plan choices for already-tuned applications.
-
- 21 8月, 2013 2 次提交
-
-
由 Bruce Momjian 提交于
Per suggestion from Vik Fearing
-
由 Andrew Dunstan 提交于
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. If this doesn't upset older compilers in the buildfarm, it will be backpatched to 9.1. Problem reported by Michael Cronenworth, although not his patch.
-
- 20 8月, 2013 7 次提交
-
-
由 Bruce Momjian 提交于
Backpatch to 9.3. Pavel Stehule
-
由 Tom Lane 提交于
sscanf isn't the easiest thing to use for exact pattern checks ... also, don't use strncmp where strcmp will do.
-
由 Alvaro Herrera 提交于
Instead of deleting all files in stats_temp_directory and the permanent directory on a crash, only remove those files that match the pattern of files we actually write in them, to avoid possibly clobbering existing unrelated contents of the temporary directory. Per complaint from Jeff Janes, and subsequent discussion, starting at message CAMkU=1z9+7RsDODnT4=cDFBRBp8wYQbd_qsLcMtKEf-oFwuOdQ@mail.gmail.com Also, fix a bug in the same routine to avoid removing files from the permanent directory twice (instead of once from that directory and then from the temporary directory), also per report from Jeff Janes, in message CAMkU=1wbk947=-pAosDMX5VC+sQw9W4ttq6RM9rXu=MjNeEQKA@mail.gmail.com
-
由 Heikki Linnakangas 提交于
This keeps the usual trigger file name unchanged from 9.2, avoiding nasty issues if you use a pre-9.3 pg_ctl binary with a 9.3 server or vice versa. The fallback behavior of creating a full checkpoint before starting up is now triggered by a file called "fallback_promote". That can be useful for debugging purposes, but we don't expect any users to have to resort to that and we might want to remove that in the future, which is why the fallback mechanism is undocumented.
-
由 Tom Lane 提交于
In an example such as SELECT * FROM i LEFT JOIN LATERAL (SELECT * FROM j WHERE i.n = j.n) j ON true; it is safe to pull up the LATERAL subquery into its parent, but we must then treat the "i.n = j.n" clause as a qual clause of the LEFT JOIN. The previous coding in deconstruct_recurse mistakenly labeled the clause as "is_pushed_down", resulting in wrong semantics if the clause were applied at the join node, as per an example submitted awhile ago by Jeremy Evans. To fix, postpone processing of such clauses until we return back up to the appropriate recursion depth in deconstruct_recurse. In addition, tighten the is-safe-to-pull-up checks in is_simple_subquery; we previously missed the possibility that the LATERAL subquery might itself contain an outer join that makes lateral references in lower quals unsafe. A regression test case equivalent to Jeremy's example was already in my commit of yesterday, but was giving the wrong results because of this bug. This patch fixes the expected output for that, and also adds a test case for the second problem.
-
由 Alvaro Herrera 提交于
When upgrading from servers of versions 9.2 and older, and MultiXactIds have been used in the old server beyond the first page (that is, 2048 multis or more in the default 8kB-page build), pg_upgrade would set the next multixact offset to use beyond what has been allocated in the new cluster. This would cause a failure the first time the new cluster needs to use this value, because the pg_multixact/offsets/ file wouldn't exist or wouldn't be large enough. To fix, ensure that the transient server instances launched by pg_upgrade extend the file as necessary. Per report from Jesse Denardo in CANiVXAj4c88YqipsyFQPboqMudnjcNTdB3pqe8ReXqAFQ=HXyA@mail.gmail.com
-
由 Bruce Momjian 提交于
Etsuro Fujita
-
- 19 8月, 2013 2 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Kevin Grittner 提交于
This was added as part of the attempt to support unlogged matviews along with a populated status. It got missed when unlogged support was removed pre-commit. Noticed by Noah Misch. Back-patched to 9.3 branch.
-
- 18 8月, 2013 3 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
The planner largely failed to consider the possibility that a PlaceHolderVar's expression might contain a lateral reference to a Var coming from somewhere outside the PHV's syntactic scope. We had a previous report of a problem in this area, which I tried to fix in a quick-hack way in commit 4da6439b, but Antonin Houska pointed out that there were still some problems, and investigation turned up other issues. This patch largely reverts that commit in favor of a more thoroughly thought-through solution. The new theory is that a PHV's ph_eval_at level cannot be higher than its original syntactic level. If it contains lateral references, those don't change the ph_eval_at level, but rather they create a lateral-reference requirement for the ph_eval_at join relation. The code in joinpath.c needs to handle that. Another issue is that createplan.c wasn't handling nested PlaceHolderVars properly. In passing, push knowledge of lateral-reference checks for join clauses into join_clause_is_movable_to. This is mainly so that FDWs don't need to deal with it. This patch doesn't fix the original join-qual-placement problem reported by Jeremy Evans (and indeed, one of the new regression test cases shows the wrong answer because of that). But the PlaceHolderVar problems need to be fixed before that issue can be addressed, so committing this separately seems reasonable.
-
- 17 8月, 2013 3 次提交
-
-
由 Bruce Momjian 提交于
Backpatch to 9.3.
-
由 Bruce Momjian 提交于
Backpatch to 9.3, of course.
-
由 Robert Haas 提交于
Per discussion on pgsql-hackers. Michael Paquier, slightly modified by me. Original suggestion from Amit Kapila.
-
- 16 8月, 2013 4 次提交
-
-
由 Bruce Momjian 提交于
Register atexit() server shutdown if pg_ctl successfully started the server, but we can't connect to it. Backpatch to 9.3. Pavel Raiskup
-
由 Heikki Linnakangas 提交于
-
由 Kevin Grittner 提交于
Was accidentally allowed, but not documented and lacked support for rename or drop once created. Per report from Noah Misch.
-
由 Magnus Hagander 提交于
-
- 15 8月, 2013 5 次提交
-
-
由 Peter Eisentraut 提交于
Timeline IDs are unsigned ints everywhere, except the replication parser treated them as signed ints.
-
由 Peter Eisentraut 提交于
Avoid using the term "updatable" in confusing ways. Suggest a trigger first, before a rule.
-
由 Tom Lane 提交于
The planner logic that attempted to make a preliminary estimate of the ph_needed levels for PlaceHolderVars seems to be completely broken by lateral references. Fortunately, the potential join order optimization that this code supported seems to be of relatively little value in practice; so let's just get rid of it rather than trying to fix it. Getting rid of this allows fairly substantial simplifications in placeholder.c, too, so planning in such cases should be a bit faster. Issue noted while pursuing bugs reported by Jeremy Evans and Antonin Houska, though this doesn't in itself fix either of their reported cases. What this does do is prevent an Assert crash in the kind of query illustrated by the added regression test. (I'm not sure that the plan for that query is stable enough across platforms to be usable as a regression test output ... but we'll soon find out from the buildfarm.) Back-patch to 9.3. The problem case can't arise without LATERAL, so no need to touch older branches.
-
由 Bruce Momjian 提交于
This syntax is supported by the parser, but is non-standard. _Not_ backpatched to 9.3 in case we change our minds.
-
由 Kevin Grittner 提交于
We don't want to prevent an extension which creates a matview from being installed in pg_catalog. Issue was raised by Hitoshi Harada. Backpatched to 9.3.
-
- 14 8月, 2013 3 次提交
-
-
由 Peter Eisentraut 提交于
Update emacs.samples with new configuration snippets that match pgindent et al. formatting more accurately and follow Emacs Lisp best practices better. Add .dir-locals.el with a subset of that configuration for casual editing and viewing. Reviewed-by: NDimitri Fontaine <dimitri@2ndQuadrant.fr> Reviewed-by: NNoah Misch <noah@leadboat.com>
-
由 Tom Lane 提交于
We've seen multiple cases of people looking at the postmaster's original stderr output to try to diagnose problems, not realizing/remembering that their logging configuration is set up to send log messages somewhere else. This seems particularly likely to happen in prepackaged distributions, since many packagers patch the code to change the factory-standard logging configuration to something more in line with their platform conventions. In hopes of reducing confusion, emit a LOG message about this at the point in startup where we are about to switch log output away from the original stderr, providing a pointer to where to look instead. This message will appear as the last thing in the original stderr output. (We might later also try to emit such link messages when logging parameters are changed on-the-fly; but that case seems to be both noticeably harder to do nicely, and much less frequently a problem in practice.) Per discussion, back-patch to 9.3 but not further.
-
由 Bruce Momjian 提交于
Move item about foreign data wrappers supporting inserts/updates/deletes to object manipulation. From Etsuro Fujita
-
- 13 8月, 2013 1 次提交
-
-
由 Bruce Momjian 提交于
We already use search_path to specify the schema, so there is no need for pg_dump to schema-qualify the name. Also remove dead code.
-