- 20 8月, 2013 4 次提交
-
-
由 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.
-
- 11 8月, 2013 1 次提交
-
-
由 Peter Eisentraut 提交于
Similar to 2cfb1c6f, the order in which dictionary elements are printed is not reliable. This reappeared in the tests of the string representation of result objects. Reduce the test case to one result set column so that there is no question of order.
-
- 10 8月, 2013 2 次提交
-
-
由 Bruce Momjian 提交于
(Yes, there was no UTC back then, but we compute it that way.) Backpatch to 9.3.
-
由 Bruce Momjian 提交于
Backpatch to 9.3. Per request from Marc Dahn
-
- 09 8月, 2013 2 次提交
-
-
由 Fujii Masao 提交于
-
由 Peter Eisentraut 提交于
-
- 08 8月, 2013 2 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Fujii Masao 提交于
In PM_WAIT_DEAD_END state, checkpointer process must be dead already. But an immediate shutdown could make postmaster's state machine transition to PM_WAIT_DEAD_END state even if checkpointer process is still running, and which caused assertion failure. This bug was introduced in commit 457d6cf0. This patch ensures that postmaster's state machine doesn't transition to PM_WAIT_DEAD_END state in an immediate shutdown while checkpointer process is running.
-
- 06 8月, 2013 2 次提交
-
-
由 Bruce Momjian 提交于
Previously only -n was recognized.
-
由 Tom Lane 提交于
Formerly, query_planner returned one or possibly two Paths for the topmost join relation, so that grouping_planner didn't see the join RelOptInfo (at least not directly; it didn't have any hesitation about examining cheapest_path->parent, though). However, correct selection of the Paths involved a significant amount of coupling between query_planner and grouping_planner, a problem which has gotten worse over time. It seems best to give up on this API choice and instead return the topmost RelOptInfo explicitly. Then grouping_planner can pull out the Paths it wants from the rel's path list. In this way we can remove all knowledge of grouping behaviors from query_planner. The only real benefit of the old way is that in the case of an empty FROM clause, we never made any RelOptInfos at all, just a Path. Now we have to gin up a dummy RelOptInfo to represent the empty FROM clause. That's not a very big deal though. While at it, simplify query_planner's API a bit more by having the caller set up root->tuple_fraction and root->limit_tuples, rather than passing those values as separate parameters. Since query_planner no longer does anything with either value, requiring it to fill the PlannerInfo fields seemed pretty arbitrary. This patch just rearranges code; it doesn't (intentionally) change any behaviors. Followup patches will do more interesting things.
-
- 05 8月, 2013 1 次提交
-
-
由 Kevin Grittner 提交于
Open and lock each index before checking definition in RMVC. The ExclusiveLock on the related table is not viewed as sufficient to ensure that no changes are made to the index definition, and invalidation messages from other backends might have been missed. Additionally, use RelationGetIndexExpressions() and check for NIL rather than doing our own loop. Protect against redefinition of tid and rowvar operators in RMVC. While working on this, noticed that the fixes for bugs found during the CF made the UPDATE statement useless, since no rows could qualify for that treatment any more. Ripping out code to support the UPDATE statement simplified the operator cleanups. Change slightly confusing local field name. Use meaningful alias names on queries in refresh_by_match_merge(). Per concerns of raised by Andres Freund and comments and suggestions from Noah Misch. Some additional issues remain, which will be addressed separately.
-
- 04 8月, 2013 1 次提交
-
-
由 Tom Lane 提交于
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 8月, 2013 2 次提交
-
-
由 Alvaro Herrera 提交于
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 3f7fbf85, 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
-
由 Alvaro Herrera 提交于
My tweak of these error messages in commit c359a1b0 contained the thinko that a query would always have rowMarks set for a query containing a locking clause. Not so: when declaring a cursor, for instance, rowMarks isn't set at the point we're checking, so we'd be dereferencing a NULL pointer. The fix is to pass the lock strength to the function raising the error, instead of trying to reverse-engineer it. The result not only is more robust, but it also seems cleaner overall. Per report from Robert Haas.
-
- 02 8月, 2013 2 次提交
-
-
由 Robert Haas 提交于
Etsuro Fujita
-
由 Bruce Momjian 提交于
Expand ops/sec by two digits to maintain alignment on servers with fast I/O subsystems, e.g. can now display < 10M ops/sec with consistent alignment.
-