Re: invalid tid errors in latest 7.3.4 stable.

On Wed, 1 Oct 2003, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> > On Wed, 1 Oct 2003, Tom Lane wrote:
> >> 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 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.
>
> An exact match would be waiting on our commit, but I was confused about
> whether ri_Check_Pk_Match could look for partial matches or not. If it

Not currently, it only checks for exact matches on fully non-NULL keys.
The only case where partial matches are needed are match partial, but the
rules are actually more complicated (because the which part needs to be
partially matched is dependant on the actual matched rows).
I guess it doesn't hurt for it to be using the current + cross check
excepting a small amount of time presumably since it shouldn't change the
results.

> can, then I'd think it might encounter rows inserted by concurrent
> transactions. OTOH maybe in serializable mode we should pretend those
> aren't there. The thing that really confused me was that it's doing a
> SELECT FOR UPDATE --- does it really need to do any row locking, if it's
> looking only for rows that our own xact inserted?

Actually, it probably doesn't. I just wasn't bright enough to think of it
to change it from the other queries at the time.

> >> 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.
>
> That was my thought also, and that the row-exists error would be more
> informative of the two, but I'm worried that I've overlooked something.

I don't see it either, but I'm also a little worried in general. Do we
have any sort of easy multi-session regression test like tools already
built for sort of lock step testing of things like this? I think I'm
going to try to run as many cases as I can come up with this week on cvs
tip.