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

Re: invalid tid errors in latest 7.3.4 stable.

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: archeron(at)wavefire(dot)com, Chris Kratz <chris(dot)kratz(at)vistashare(dot)com>,pgsql-hackers(at)postgresql(dot)org, Jan Wieck <JanWieck(at)Yahoo(dot)com>
Subject: Re: invalid tid errors in latest 7.3.4 stable.
Date: 2003-10-01 22:19:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, 1 Oct 2003, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> > On Tue, 30 Sep 2003, Tom Lane wrote:
> >> I think I can implement it and it will act as stated in my proposal.
> >> Whether people like the proposed behavior is the big question in my
> >> mind.
> > I think it's more reasonable than the current behavior or any of
> > the others we've hit along the way, and we have to pretty much choose
> > now if we want to change it for 7.4.
> I've committed the attached patch.  One thing I wanted to double-check
> with you is that the SELECT FOR UPDATES done in the noaction cases are
> being correctly handled.  I think it is correct to do them with the
> current snapshot rather than the start-of-transaction snap; do you
> agree?  Also, I did not propagate the crosscheck support into

I think the ones in the main functions need to be current snapshot.  I
think the one in ri_Check_Pk_Match doesn't need to be. That's there to see
if this same transaction has inserted a new row with the old value of the
updated/deleted pk row and the serializable snapshot should be fine.
Any conflicting attempts from another transaction should be waiting on our
completion due to the unique index I think.

> heap_mark4update, meaning that these SELECT FOR UPDATEs won't complain
> if they find a row that was inserted later than the start of the
> serializable transaction.  I'm not totally sure if they should or not;
> what do you think?

Well, I think that not doing so would only change the error from a
serialization error to a matching row exists error.  It might be a bit
surprising if you've just done a select yourself and seen that there were
no matching rows, but I'm not sure that it's a big deal as long as it
errors as appropriate.

In response to


pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2003-10-01 22:23:16
Subject: Re: Thoughts on maintaining 7.3
Previous:From: Tom LaneDate: 2003-10-01 22:11:18
Subject: Re: Thoughts on maintaining 7.3

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