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

Re: advancing snapshot's xmin

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Cc: "Neil Conway" <neilc(at)samurai(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: advancing snapshot's xmin
Date: 2008-03-26 01:46:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Neil Conway wrote:
>> If we're just updating MyProc->xmin, we only need to acquire
>> ProcArrayLock in shared mode, right?

> In fact, do you need a lock at all?

I think you probably do.  GetSnapshotData needs to be confident that the
global xmin it computes is <= the xmin that any other backend might be
about to store into its MyProc->xmin; how can you ensure that if there's
no locking happening?

Now the way I'd been envisioning this would work is that whenever the
number of active snapshots goes to zero, we clear MyProc->xmin, and
that probably could be done without a lock.  Then the next time we do 
GetSnapshotData, it would compute and store a new MyProc->xmin
(this would be the same activity that we currently think of as "setting
the serializable snapshot").  So you don't need any more locking than
already exists.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2008-03-26 01:50:56
Subject: Re: Reducing Transaction Start/End Contention
Previous:From: Bruce MomjianDate: 2008-03-26 01:42:38
Subject: Re: stored procedure stats in collector

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