Re: Savepoint weirdness

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

In response to

Browse pgsql-hackers by date

  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