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

advancing snapshot's xmin

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: advancing snapshot's xmin
Date: 2008-03-25 20:26:45
Message-ID: 20080325202645.GA15520@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi,

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


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.

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.

Another idea is to throttle the updating of Xmin so it only happens once
in a while, but it's difficult to find a useful criterion and avoid
falling into the trap that we just neglected to update it before a large
command.


Thoughts?

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

Responses

pgsql-hackers by date

Next:From: Richard BroersmaDate: 2008-03-25 20:26:46
Subject: Re: PostgreSQL Replication with read-only access to standby DB
Previous:From: Dimitri FontaineDate: 2008-03-25 20:25:40
Subject: Re: GiST opclass and varlena

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