Add some notes about why it's not a bug that RI_FKey_check calls

HeapTupleSatisfiesItself without doing LockBuffer first.  This code
is a bit fragile, but AFAICS it's not actually broken.

diff --git a/src/backend/utils/adt/ri_triggers.c b/src/backend/utils/adt/ri_triggers.c
index 198d988df7c82ee9f2642e6dd1d5087d19b2180d..012556cec0bd6cc77ce469f0d6a70a3e15a6e5c6 100644 (file)
--- a/src/backend/utils/adt/ri_triggers.c
+++ b/src/backend/utils/adt/ri_triggers.c
@@ -212,9 +212,19 @@ RI_FKey_check(PG_FUNCTION_ARGS)
        }
 
        /*
-        * We should not even consider checking the row if it is no longer valid
-        * since it was either deleted (doesn't matter) or updated (in which case
-        * it'll be checked with its final values).
+        * We should not even consider checking the row if it is no longer valid,
+        * since it was either deleted (so the deferred check should be skipped)
+        * or updated (in which case only the latest version of the row should
+        * be checked).  Test its liveness with HeapTupleSatisfiesItself.
+        *
+        * NOTE: The normal coding rule is that one must acquire the buffer
+        * content lock to call HeapTupleSatisfiesFOO.  We can skip that here
+        * because we know that AfterTriggerExecute just fetched the tuple
+        * successfully, so there cannot be a VACUUM compaction in progress
+        * on the page (either heap_fetch would have waited for the VACUUM,
+        * or the VACUUM's LockBufferForCleanup would be waiting for us to drop
+        * pin).  And since this is a row inserted by our open transaction,
+        * no one else can be entitled to change its xmin/xmax.
         */
        Assert(new_row_buf != InvalidBuffer);
        if (!HeapTupleSatisfiesItself(new_row->t_data, new_row_buf))