Re: Proposal: Snapshot cloning - Mailing list pgsql-hackers
From | Jan Wieck |
---|---|
Subject | Re: Proposal: Snapshot cloning |
Date | |
Msg-id | 45BA3DDA.5090607@Yahoo.com Whole thread Raw |
In response to | Re: Proposal: Snapshot cloning ("Simon Riggs" <simon@2ndquadrant.com>) |
Responses |
Re: Proposal: Snapshot cloning
("Simon Riggs" <simon@2ndquadrant.com>)
|
List | pgsql-hackers |
On 1/26/2007 12:22 PM, Simon Riggs wrote: > On Fri, 2007-01-26 at 11:36 -0500, Tom Lane wrote: >> "Simon Riggs" <simon@2ndquadrant.com> writes: >> > No, that would break MVCC. But we may have done lots of updates/deletes >> > that are *not* visible to any Snapshot, yet are not yet removable >> > because they are higher than OldestXmin but we don't know that because >> > previously the Snapshot details were not available. ISTM that this >> > proposal is a way of making the Snapshot limits publicly available so >> > that they can be used by VACUUM. >> >> Certainly not, unless you intend that *every* snapshot *must* be >> published, which is an overhead up with which we will not put. > > Agreed, but that's the general case problem. > > What I was hoping was that this would provide a mechanism for long > running transactions (LRTs) to publish their min/max Xids. Then if all > backends publish the minimum Xid of any Snapshot they have generated in > the proc array, we'd be able to decide if there are any large holes in > the global set of Snapshots. As a general case that's hard to evaluate, > but in the common case of a lone LRT and all the rest short duration > transactions you can end up with a gap of 250,000+ transactions opening > up between the two. It would be fairly easy to have VACUUM check for > large "visibility gaps" between groups of transactions and then use that > to improve its effectiveness in the presence of LRTs. There is a flaw in that theory. If you have a single LTR, then each subsequent transactions xmin will be exactly that one, no? Jan > > Theoretically we have to keep the chain of intermediate updates around > so it can be traversed by the old transaction, but in practical terms > traversing a long chain of updates isn't sensible. Serializable LRTs > will never traverse the chain anyway (that's a serializability error), > but there are some special cases to consider, hence my mentioning an > unresolved problem previously. > > We'd need to be much more careful about the way Snapshots are managed, > so we can be certain that we take them all into account. > -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
pgsql-hackers by date: