From: Thomas Munro Date: Tue, 13 Apr 2021 00:34:25 +0000 (+1200) Subject: Fix potential SSI hazard in heap_update(). X-Git-Tag: REL_13_3~40 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=16175e278763e88618c814b6489c4ae795501282;p=thirdparty%2Fpostgresql.git 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 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 e13f0a86103..7b2c19b468a 100644 --- 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