Re: XID wraparound and busy databases

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Robert Treat" <xzilla(at)users(dot)sourceforge(dot)net>, "Decibel!" <decibel(at)decibel(dot)org>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: XID wraparound and busy databases
Date: 2007-08-16 02:26:59
Message-ID: 14760.1187231219@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> You wouldn't take a new snapshot. The thought that occurs to me is that
>> there's no reason that a transaction has to have an XID for itself
>> before it takes a snapshot. We always special-case our own XID anyway.

> I'm having trouble picturing how that would work with a transaction using
> the SERIALIZABLE transaction isolation level,

Why? You take a snapshot, you use it. If you later need to allocate an
XID for yourself, you do that --- your own XID is surely uncommitted in
any case, so this doesn't affect the validity of the snapshot.

The bottom line here is that we need own-XID-if-any to be >= snapshot
xmin, but there's no obvious reason why it has to be < snapshot xmax.
This is, in fact, *not* the case for subtransaction XIDs, and I see
no fundamental reason why it need be true for the top transaction XID.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Decibel! 2007-08-16 03:52:21 Re: Another idea for index-only scans
Previous Message Kevin Grittner 2007-08-15 22:58:19 Re: XID wraparound and busy databases