Skip site navigation (1) Skip section navigation (2)

Re: Proposal: Snapshot cloning

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hannu Krosing <hannu(at)skype(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Snapshot cloning
Date: 2007-01-26 17:43:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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(at)2ndquadrant(dot)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?


> 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(at)Yahoo(dot)com #

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-01-26 17:59:49
Subject: Re: Recursive query syntax ambiguity
Previous:From: Gregory StarkDate: 2007-01-26 17:41:26
Subject: Recursive query syntax ambiguity

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group