postgres.git / summary / log / commit / refs

commit    b1df6b696b759f00ebbf02e6de64e259d4be5785
Author:   Thomas Munro <tmunro@postgresql.org>
Date:     Tue Apr 13 00:34:25 2021 +0000
First released in: 14.0, 13.3

    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


 src/backend/access/heap/heapam.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 03d4abc938b..548720021ed 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -3900,7 +3900,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


[parent: 885a87641930]