Re: advancing snapshot's xmin

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "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 09:23:06
Message-ID: 87y785ltz9.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> "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?

Surely xmin would only ever advance? How can removing snapshots cause xmin to
retreat at all, let alone behind the gloal xmin GetSnapshotData calculated?

> 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.

It's the same locking in theory from the point of view of where in the code
the locking happens. But I don't think it's the same locking in practice from
the point of view of how much wall-clock time passes between locks.

Consider a data loading job which has millions of INSERT statements in a file.
Currently if you put them all in a transaction it takes a single snapshot and
runs them all with the same snapshot.

If you reset xmin whenever you have no live snapshots then that job would be
doing that between every INSERT statement.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2008-03-26 10:39:33 Re: New email list for emergency communications
Previous Message Dimitri Fontaine 2008-03-26 08:51:31 Re: PostgreSQL Replication with read-only access to standby DB