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

Re: advancing snapshot's xmin

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: advancing snapshot's xmin
Date: 2008-03-28 13:35:10
Message-ID: 20080328133510.GK7464@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:

> What I'm envisioning is that we lose the notion of "this is a
> serializable snapshot" that that function currently has, and just
> give it the rule "if MyProc->xmin is currently zero, then set it".
> Then the only additional mechanism needed is for the snapshot
> manager to detect when all snapshots are gone and zero out
> MyProc->xmin --- that would happen sometime during command shutdown,
> and per current discussion it shouldn't need a lock.

This is all easily done -- it's just a couple of extra lines.

However I am now having a definitional problem.  Perhaps it is so
obvious to everyone else that nobody bothered mentioning it.  I know I
wasn't aware until I tried a simple test and found that the Xmin wasn't
advancing as I was expecting.

The problem is that we always consider every transaction's PGPROC->xid
in calculating MyProc->xmin.  So if you have a long running transaction,
it doesn't matter how far beyond the snapshots are -- the value returned
by GetOldestXmin will always be at most the old transaction's Xid.  Even
if that transaction cannot see the old rows because all of its snapshots
are way in the future.

As far as I can see, for the purposes of VACUUM we can remove any tuple
that was deleted after the old transaction's Xid but before that
transaction's Xmin (i.e. all of its live snapshots).  This means we get
to ignore Xid in GetOldestXmin and in the TransactionXmin calculations
in GetSnapshotData.  It would not surprise me, however, to find out that
I am overlooking something and this is incorrect.

Am I blind?

It is quite possible that for the other purposes that we're using Xmins
for, this is not so.  If that's the case, I would argue that we would
need to introduce a separate TransactionId to keep track of, which would
retain the current semantics of Xmin, and let VACUUM use what I am
proposing.  I haven't examined those other uses though.

Thoughs?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2008-03-28 13:37:29
Subject: Prereading using posix_fadvise (was Re: Commitfest patches)
Previous:From: Alvaro HerreraDate: 2008-03-28 12:21:36
Subject: Re: Problem identifying constraints which should not beinherited

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