Re: First-draft release notes for next week's releases

Alvaro Herrera <alvherre@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