On Mon, Jul 18, 2016 at 12:47 PM, Andres Freund <andres@anarazel.de> wrote:
as far as I can see that could mean that we perform hot updates when not permitted, because the tuple has been replaced since, including the pkey. Similarly, the wrong tuple lock mode could end up being used.
Am I missing something?
If the to-be-updated tuple gets updated while we were retrying vm pinning, heap_update() should return HeapTupleUpdated and the caller must wait for the updating transaction to finish, retry update with the new version (or fail depending on the isolation level). Given that HeapTupleSatisfiesUpdate() is called after l2, the logic seems fine to me.
