From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Savepoint weirdness |
Date: | 2004-08-15 21:26:55 |
Message-ID: | Pine.LNX.4.58.0408160722210.6148@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 15 Aug 2004, Tom Lane wrote:
> Gavin Sherry <swm(at)linuxworld(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Eric Kerin | 2004-08-15 21:58:46 | Re: will PITR in 8.0 be usable for "hot spare"/"log |
Previous Message | Gaetano Mendola | 2004-08-15 20:22:02 | Re: will PITR in 8.0 be usable for "hot spare"/"log |