Ensure we have a snapshot when updating various system catalogs.
authorNathan Bossart <[email protected]>
Fri, 30 May 2025 20:17:28 +0000 (15:17 -0500)
committerNathan Bossart <[email protected]>
Fri, 30 May 2025 20:17:28 +0000 (15:17 -0500)
A few places that access system catalogs don't set up an active
snapshot before potentially accessing their TOAST tables.  To fix,
push an active snapshot just before each section of code that might
require accessing one of these TOAST tables, and pop it shortly
afterwards.  While at it, this commit adds some rather strict
assertions in an attempt to prevent such issues in the future.

Commit 16bf24e0e4 recently removed pg_replication_origin's TOAST
table in order to fix the same problem for that catalog.  On the
back-branches, those bugs are left in place.  We cannot easily
remove a catalog's TOAST table on released major versions, and only
replication origins with extremely long names are affected.  Given
the low severity of the issue, fixing older versions doesn't seem
worth the trouble of significantly modifying the patch.

Also, on v13 and v14, the aforementioned strict assertions have
been omitted because commit 2776922201, which added
HaveRegisteredOrActiveSnapshot(), was not back-patched.  While we
could probably back-patch it now, I've opted against it because it
seems unlikely that new TOAST snapshot issues will be introduced in
the oldest supported versions.

Reported-by: Alexander Lakhin <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/18127-fe54b6a667f29658%40postgresql.org
Discussion: https://postgr.es/m/18309-c0bf914950c46692%40postgresql.org
Discussion: https://postgr.es/m/ZvMSUPOqUU-VNADN%40nathan
Backpatch-through: 13

src/backend/commands/indexcmds.c
src/backend/postmaster/autovacuum.c

index e0295d7b8aeb9d2eaccf03ccb23e37272cfccd7b..f7c09a632425dcaea9a369ddbbf30df244af307e 100644 (file)
@@ -3519,12 +3519,20 @@ ReindexRelationConcurrently(Oid relationOid, int options)
                                     get_rel_namespace(heapId),
                                     false);
 
+       /*
+        * Swapping the indexes might involve TOAST table access, so ensure we
+        * have a valid snapshot.
+        */
+       PushActiveSnapshot(GetTransactionSnapshot());
+
        /*
         * Swap old index with the new one.  This also marks the new one as
         * valid and the old one as not valid.
         */
        index_concurrently_swap(newIndexId, oldIndexId, oldName);
 
+       PopActiveSnapshot();
+
        /*
         * Invalidate the relcache for the table, so that after this commit
         * all sessions will refresh any cached plans that might reference the
index 59fcc8b93f096548936ea39370764068ed974a0f..23cca675f0065c33949617653858e113e0a4c8ba 100644 (file)
@@ -2294,6 +2294,12 @@ do_autovacuum(void)
                        get_namespace_name(classForm->relnamespace),
                        NameStr(classForm->relname))));
 
+       /*
+        * Deletion might involve TOAST table access, so ensure we have a
+        * valid snapshot.
+        */
+       PushActiveSnapshot(GetTransactionSnapshot());
+
        object.classId = RelationRelationId;
        object.objectId = relid;
        object.objectSubId = 0;
@@ -2306,6 +2312,7 @@ do_autovacuum(void)
         * To commit the deletion, end current transaction and start a new
         * one.  Note this also releases the locks we took.
         */
+       PopActiveSnapshot();
        CommitTransactionCommand();
        StartTransactionCommand();