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

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 16:29:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Uhm, yeah, I somehow didn't write was I was thinking. I didn't mean to say we
>> would be taking a new snapshot for each INSERT but that we would be resetting
>> xmin for each INSERT. Whereas currently we only set xmin once when we set the
>> serializable snapshot.
> Right, but setting xmin within GetSnapshotData is essentially free.
> 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.

It would be nice if there was some way to notice that no other transactions
have committed since last we calculated a snapshot and just reuse that

I would say ideally before we throw out our xmin but I suspect the point of
synchronization needed to notice this condition would be tantamount to that
same lock anyways.

  Gregory Stark
  Ask me about EnterpriseDB's RemoteDBA services!

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-03-26 16:39:52
Subject: Re: [COMMITTERS] pgsql: Strengthen warnings about using pg_dump's -i option.
Previous:From: Zdenek KotalaDate: 2008-03-26 16:24:18
Subject: Re: Script binaries renaming

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