- 04 3月, 2011 1 次提交
-
-
由 Tom Lane 提交于
This works around the problem noted by Yamamoto Takashi in bug #5906, that there were code paths whereby we could reach AtCleanup_Portals with a portal's cleanup hook still unexecuted. The changes I made a few days ago were intended to prevent that from happening, and I think that on balance it's still a good thing to avoid, so I don't want to remove the Assert in AtCleanup_Portals. Hence do this instead.
-
- 03 3月, 2011 10 次提交
-
-
由 Michael Meskes 提交于
Andy Colson <andy@squeakycode.net>.
-
由 Heikki Linnakangas 提交于
Andrey Popp
-
由 Tom Lane 提交于
Now that btree_gist contains a reference to isinf(), this is necessary at least on some platforms. Per buildfarm.
-
由 Tom Lane 提交于
Historically, we've not had separate comments for built-in pg_operator entries, but relied on the comments for the underlying functions. The trouble with this approach is that there isn't much of anything to suggest to users that they'd be better off using the operators instead. So, move all the relevant comments into pg_operator, and give each underlying function a comment that just says "implementation of XXX operator". There are only about half a dozen cases where it seems reasonable to use the underlying function interchangeably with the operator; in these cases I left the same comment in place on the function as on the operator. While at it, establish a policy that every built-in function and operator entry should have a comment: there are now queries in the opr_sanity regression test that will complain if one doesn't. This only required adding a dozen or two more entries than would have been there anyway. I also spent some time trying to eliminate gratuitous inconsistencies in the style of the comments, though it's hopeless to suppose that more won't creep in soon enough. Per my proposal of 2010-10-15.
-
由 Peter Eisentraut 提交于
This is faked information like for domains.
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
This extends GiST's support for nearest-neighbor searches to many of the standard data types. Teodor Sigaev
-
由 Peter Eisentraut 提交于
Mapped to NetBSD, the closest existing match. (Even though DragonFly BSD is derived from FreeBSD, the shared library version numbering matches NetBSD, and the rest is mostly the same among all BSD variants.) per "Rumko"
-
由 Tom Lane 提交于
Time spent executing AFTER triggers is not included in the runtime of the associated ModifyTable node; in my patch of yesterday I confused queuing of these triggers with their actual execution. Spotted by Marko Tiikkaja.
-
- 02 3月, 2011 8 次提交
-
-
由 Andrew Dunstan 提交于
Patch from Jan Urbański.
-
由 Peter Eisentraut 提交于
plpython_subtransaction test needs a separate expected file specifically for Python 2.5.
-
由 Heikki Linnakangas 提交于
it a lot more useful for determining which standby is most up-to-date, for example. There was long discussions on whether overwriting existing existing WAL makes sense to begin with, and whether we should do some more extensive variable renaming, but this change nevertheless seems quite uncontroversial. Fujii Masao, reviewed by Jeff Janes, Robert Haas, Stephen Frost.
-
由 Heikki Linnakangas 提交于
Change the way UPDATEs are handled. Instead of maintaining a chain of tuple-level locks in shared memory, copy any existing locks on the old tuple to the new tuple at UPDATE. Any existing page-level lock needs to be duplicated too, as a lock on the new tuple. That was neglected previously. Store xmin on tuple-level predicate locks, to distinguish a lock on an old already-recycled tuple from a new tuple at the same physical location. Failure to distinguish them caused loops in the tuple-lock chains, as reported by YAMAMOTO Takashi. Although we don't use the chain representation of UPDATEs anymore, it seems like a good idea to store the xmin to avoid some false positives if no other reason. CheckSingleTargetForConflictsIn now correctly handles the case where a lock that's being held is not reflected in the local lock table. That happens if another backend acquires a lock on our behalf due to an UPDATE or a page split. PredicateLockPageCombine now retains locks for the page that is being removed, rather than removing them. This prevents a potentially dangerous false-positive inconsistency where the local lock table believes that a lock is held, but it is actually not. Dan Ports and Kevin Grittner
-
由 Peter Eisentraut 提交于
This was previously omitted by accident.
-
由 Tom Lane 提交于
Back-patch to 9.0, since this was changed then.
-
由 Tom Lane 提交于
Per discussion, this seems important for plans involving writable CTEs, since there can now be more than one ModifyTable node in the plan. To retain the same formatting as for target tables of scan nodes, we show only one target table, which will be the parent table in case of an UPDATE or DELETE on an inheritance tree. Individual child tables can be determined by inspecting the child plan trees if needed.
-
由 Robert Haas 提交于
Without this patch, when wal_receiver_status_interval=0, indicating that no status messages should be sent, Hot Standby feedback messages are instead sent extremely frequently. Fujii Masao, with documentation changes by me.
-
- 01 3月, 2011 5 次提交
-
-
由 Tom Lane 提交于
With this patch, portals, SQL functions, and SPI all agree that there should be only a CommandCounterIncrement between the queries that are generated from a single SQL command by rule expansion. Fetching a whole new snapshot now happens only between original queries. This is equivalent to the existing behavior of EXPLAIN ANALYZE, and it was judged to be the best choice since it eliminates one source of concurrency hazards for rules. The patch should also make things marginally faster by reducing the number of snapshot push/pop operations. The patch removes pg_parse_and_rewrite(), which is no longer used anywhere. There was considerable discussion about more aggressive refactoring of the query-processing functions exported by postgres.c, but for the moment nothing more has been done there. I also took the opportunity to refactor snapmgr.c's API slightly: the former PushUpdatedSnapshot() has been split into two functions. Marko Tiikkaja, reviewed by Steve Singer and Tom Lane
-
由 Andrew Dunstan 提交于
-
由 Robert Haas 提交于
For consistency with pg_last_xlog_replay_location. Per discussion.
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
This provides a separate exception class for each error code that the backend defines, as well as the ability to get the SQLSTATE from the exception object. Jan Urbański, reviewed by Steve Singer
-
- 28 2月, 2011 6 次提交
-
-
由 Tom Lane 提交于
Marko Tiikkaja, somewhat reworked by Tom
-
由 Bruce Momjian 提交于
-
由 Peter Eisentraut 提交于
Adds a context manager, obtainable by plpy.subtransaction(), to run a group of statements in a subtransaction. Jan Urbański, reviewed by Steve Singer, additional scribbling by me
-
由 Peter Eisentraut 提交于
We don't have complete expected coverage for Python 2.2 anyway, so it doesn't seem worth keeping this one around that no one appears to be updating anyway. Visual inspection of the differences ought to be good enough for those few who care about this obsolete Python version.
-
由 Tom Lane 提交于
The originally committed patch for modifying CTEs didn't interact well with EXPLAIN, as noted by myself, and also had corner-case problems with triggers, as noted by Dean Rasheed. Those problems show it is really not practical for ExecutorEnd to call any user-defined code; so split the cleanup duties out into a new function ExecutorFinish, which must be called between the last ExecutorRun call and ExecutorEnd. Some Asserts have been added to these functions to help verify correct usage. It is no longer necessary for callers of the executor to call AfterTriggerBeginQuery/AfterTriggerEndQuery for themselves, as this is now done by ExecutorStart/ExecutorFinish respectively. If you really need to suppress that and do it for yourself, pass EXEC_FLAG_SKIP_TRIGGERS to ExecutorStart. Also, refactor portal commit processing to allow for the possibility that PortalDrop will invoke user-defined code. I think this is not actually necessary just yet, since the portal-execution-strategy logic forces any non-pure-SELECT query to be run to completion before we will consider committing. But it seems like good future-proofing.
-
由 Bruce Momjian 提交于
output of actual Postgres parameter _values_ related to shared memory, and suggesting that these are only possible parameters to reduce.
-
- 27 2月, 2011 6 次提交
-
-
由 Magnus Hagander 提交于
Josh Kupershmidt
-
由 Bruce Momjian 提交于
per suggestion from Andrew.
-
由 Heikki Linnakangas 提交于
sender is immediately woken up by transaction commit, there's no need to wake up so aggressively.
-
由 Andrew Dunstan 提交于
-
由 Bruce Momjian 提交于
pg_attribute.attoptions.
-
由 Bruce Momjian 提交于
-
- 26 2月, 2011 4 次提交
-
-
由 Peter Eisentraut 提交于
This allows functions with multiple OUT parameters returning both one or multiple records (RECORD or SETOF RECORD). Jan Urbański, reviewed by Hitoshi Harada
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
We need ExecutorEnd to run the ModifyTable nodes to completion in reverse order of initialization, not forward order. Easily done by constructing the list back-to-front.
-
由 Tom Lane 提交于
This patch implements data-modifying WITH queries according to the semantics that the updates all happen with the same command counter value, and in an unspecified order. Therefore one WITH clause can't see the effects of another, nor can the outer query see the effects other than through the RETURNING values. And attempts to do conflicting updates will have unpredictable results. We'll need to document all that. This commit just fixes the code; documentation updates are waiting on author. Marko Tiikkaja and Hitoshi Harada
-