Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > Uhm. But at the bottom of that block, right above the "failed:" label > (heapam.c line 4527 in current master), we recheck the tuple for > "locked-only-ness"; and fail the whole operation by returning > HeapTupleUpdated, if it's not locked-only, no? Which would cause > ExecLockRows to grab the next version via EvalPlanQualFetch. > Essentially that check is a lock-conflict test, and the only thing that > does not conflict with an update is a FOR KEY SHARE lock.
Right, the row-lock acquisition has to succeed for there to be a risk. I wasn't sure whether 9.3 had introduced any such cases for existing row lock types. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers