summaryrefslogtreecommitdiff
path: root/src/backend/tcop
diff options
context:
space:
mode:
authorTom Lane2021-10-01 15:10:12 +0000
committerTom Lane2021-10-01 15:10:12 +0000
commit04ef2021e3ca7207b87ffce437b0b4db73a7f6b2 (patch)
treeb78ca53d74decf30106660f9bab9424459ea6b37 /src/backend/tcop
parent649e561f65c579630e5c31ee65308eefdd21ec93 (diff)
Fix Portal snapshot tracking to handle subtransactions properly.
Commit 84f5c2908 forgot to consider the possibility that EnsurePortalSnapshotExists could run inside a subtransaction with lifespan shorter than the Portal's. In that case, the new active snapshot would be popped at the end of the subtransaction, leaving a dangling pointer in the Portal, with mayhem ensuing. To fix, make sure the ActiveSnapshot stack entry is marked with the same subtransaction nesting level as the associated Portal. It's certainly safe to do so since we won't be here at all unless the stack is empty; hence we can't create an out-of-order stack. Let's also apply this logic in the case where PortalRunUtility sets portalSnapshot, just to be sure that path can't cause similar problems. It's slightly less clear that that path can't create an out-of-order stack, so add an assertion guarding it. Report and patch by Bertrand Drouvot (with kibitzing by me). Back-patch to v11, like the previous commit. Discussion: https://postgr.es/m/ff82b8c5-77f4-3fe7-6028-fcf3303e82dd@amazon.com
Diffstat (limited to 'src/backend/tcop')
-rw-r--r--src/backend/tcop/pquery.c27
1 files changed, 20 insertions, 7 deletions
diff --git a/src/backend/tcop/pquery.c b/src/backend/tcop/pquery.c
index 5781dcde7c6..a8f65ca1658 100644
--- a/src/backend/tcop/pquery.c
+++ b/src/backend/tcop/pquery.c
@@ -480,7 +480,9 @@ PortalStart(Portal portal, ParamListInfo params,
* We could remember the snapshot in portal->portalSnapshot,
* but presently there seems no need to, as this code path
* cannot be used for non-atomic execution. Hence there can't
- * be any commit/abort that might destroy the snapshot.
+ * be any commit/abort that might destroy the snapshot. Since
+ * we don't do that, there's also no need to force a
+ * non-default nesting level for the snapshot.
*/
/*
@@ -1134,9 +1136,15 @@ PortalRunUtility(Portal portal, PlannedStmt *pstmt,
snapshot = RegisterSnapshot(snapshot);
portal->holdSnapshot = snapshot;
}
- /* In any case, make the snapshot active and remember it in portal */
- PushActiveSnapshot(snapshot);
- /* PushActiveSnapshot might have copied the snapshot */
+
+ /*
+ * In any case, make the snapshot active and remember it in portal.
+ * Because the portal now references the snapshot, we must tell
+ * snapmgr.c that the snapshot belongs to the portal's transaction
+ * level, else we risk portalSnapshot becoming a dangling pointer.
+ */
+ PushActiveSnapshotWithLevel(snapshot, portal->createLevel);
+ /* PushActiveSnapshotWithLevel might have copied the snapshot */
portal->portalSnapshot = GetActiveSnapshot();
}
else
@@ -1786,8 +1794,13 @@ EnsurePortalSnapshotExists(void)
elog(ERROR, "cannot execute SQL without an outer snapshot or portal");
Assert(portal->portalSnapshot == NULL);
- /* Create a new snapshot and make it active */
- PushActiveSnapshot(GetTransactionSnapshot());
- /* PushActiveSnapshot might have copied the snapshot */
+ /*
+ * Create a new snapshot, make it active, and remember it in portal.
+ * Because the portal now references the snapshot, we must tell snapmgr.c
+ * that the snapshot belongs to the portal's transaction level, else we
+ * risk portalSnapshot becoming a dangling pointer.
+ */
+ PushActiveSnapshotWithLevel(GetTransactionSnapshot(), portal->createLevel);
+ /* PushActiveSnapshotWithLevel might have copied the snapshot */
portal->portalSnapshot = GetActiveSnapshot();
}