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

Re: advancing snapshot's xmin

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: advancing snapshot's xmin
Date: 2008-03-25 22:32:05
Message-ID: 1206484325.4285.1095.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 2008-03-25 at 17:26 -0300, Alvaro Herrera wrote:

> I've finished (hopefully) the code to handle a current list of open
> snapshots in a transaction.  I'm now wondering how to put it to good use
> ;-)  I'm not posting it yet -- first I want to get some feedback on the
> previous patch I posted,
> http://archives.postgresql.org/pgsql-patches/2008-03/msg00245.php

As I said before, it looks fine. In your words, it "just moves code
around", so there's not much to complain about.

> I think the important change here is switching the semantics of
> MyProc->xmin.  Currently, it is "the minimum of Xmin and Xid, across all
> backends, at the moment the current transaction fetches its serializable
> snapshot".  The first important bit is that it is computed only once:
> when the serializable snapshot is taken.

Yes, I see that as necessary. So the refactoring makes sense, since
we'll be adding lots of stuff in that area and its good to keep it
isolated.

> So ISTM the important change is that we will have to update MyProc->xmin
> more frequently than that.  I'm thinking in keeping enough local state
> so that we can detect at what time the earliest open snapshot is
> unregistered; when that happens, we can recalculate MyProc->xmin based
> on the snapshots we have and the Xid/Xmin of remote backends (which
> could have also been updating their own xmins).
> 
> There is one hole here: contention on ProcArrayLock.  Basically, for
> simple transactions we will need to update MyProc after every command.
> It has been reported that ProcArrayLock is the most contended lock for
> some loads; this would only add to that, and heavily I think.  Perhaps
> we could restructure the locking here somehow to avoid this problem, but
> it is complex enough already that it may not even be possible.

I don't see that this would be a contention problem.

We are already careful to read the xmin just once during
GetSnapshotData(). We advance it while holding only a LW_SHARED lock
during a serializable snapshot, so not sure why we wouldn't advance it
at other times also without contention issues. Why does anyone else know
or care whether we're taking a serializable snapshot or not?

The issue is whether we agree that is correct to do so. If we're
advancing it in the circumstances you say, then yes I agree it is.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com 

  PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk


In response to

pgsql-hackers by date

Next:From: Richard BroersmaDate: 2008-03-25 22:32:57
Subject: Re: PostgreSQL Replication with read-only access to standby DB
Previous:From: Simon RiggsDate: 2008-03-25 22:08:44
Subject: Re: PostgreSQL Replication with read-only access tostandby DB

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