Stephan Szabo <sszabo@megazone.bigpanda.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
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?
>> 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.
regards, tom lane
