Fix potential SSI hazard in heap_update().

Commit 6f38d4dac38 failed to heed a warning about the stability of the
value pointed to by "otid".  The caller is allowed to pass in a pointer to
newtup->t_self, which will be updated during the execution of the
function.  Instead, the SSI check should use the value we copy into
oldtup.t_self near the top of the function.

Not a live bug, because newtup->t_self doesn't really get updated until
a bit later, but it was confusing and broke the rule established by the
comment.

Back-patch to 13.

Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/2689164.1618160085%40sss.pgh.pa.us

diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index e13f0a8610343a0a905c700f467b61cb89a3c0e9..7b2c19b468a456da7e5f31e68c80d0e9dc32172d 100644 (file)
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -3561,7 +3561,8 @@ l2:
     * will include checking the relation level, there is no benefit to a
     * separate check for the new tuple.
     */
-   CheckForSerializableConflictIn(relation, otid, BufferGetBlockNumber(buffer));
+   CheckForSerializableConflictIn(relation, &oldtup.t_self,
+                                  BufferGetBlockNumber(buffer));
 
    /*
     * At this point newbuf and buffer are both pinned and locked, and newbuf