Re: Savepoint weirdness - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: Savepoint weirdness
Date
Msg-id Pine.LNX.4.58.0408160722210.6148@linuxworld.com.au
Whole thread Raw
In response to Re: Savepoint weirdness  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, 15 Aug 2004, Tom Lane wrote:

> Gavin Sherry <swm@linuxworld.com.au> writes:
> > Jason Godden pointed out some weird savepoint behaviour on IRC and i've
> > narrowed this down to a simpler case.
>
> The answer turns out to be that GetSnapshotData is miscomputing snapshot
> xmin and RecentGlobalXmin when inside a subtransaction: it omits our own
> top transaction ID from the set of open transactions.  The presence of
> the unique index makes a difference because in the unique-index-check
> code, we check the existing rows using the bogus data, and actually end
> up concluding that the original rows being updated are globally dead,
> and marking them so.

Yeah. I was scratching my head for a while wondering why a unique index
would make a difference. I was on the look out for something which screwed
up xmin but assumed it must have been within the unique check since that
is that triggered the problem for me (i'd tested delete and insert).

> I'm surprised that we didn't find this one much earlier :-(

Yeah. It came from Jason writing a proper application which used
savepoints.

Gavin


pgsql-hackers by date:

Previous
From: Gaetano Mendola
Date:
Subject: Re: will PITR in 8.0 be usable for "hot spare"/"log
Next
From: Eric Kerin
Date:
Subject: Re: will PITR in 8.0 be usable for "hot spare"/"log