@@ -954,12 +954,7 @@ xmin_cmp(const pairingheap_node *a, const pairingheap_node *b, void *arg)
954954 *
955955 * If there are no more snapshots, we can reset our PGXACT->xmin to InvalidXid.
956956 * Note we can do this without locking because we assume that storing an Xid
957- * is atomic. We do this because it will allow multi-statement transactions to
958- * reset their xmin and prevent us from holding back removal of dead rows;
959- * this has little purpose when we are dealing with very fast statements in
960- * read committed mode since the xmin will advance quickly anyway. It has no
961- * use at all when we are running single statement transactions since the xmin
962- * is reset as part of end of transaction anyway.
957+ * is atomic.
963958 *
964959 * Even if there are some remaining snapshots, we may be able to advance our
965960 * PGXACT->xmin to some degree. This typically happens when a portal is
@@ -1056,7 +1051,7 @@ AtSubAbort_Snapshot(int level)
10561051 * Snapshot manager's cleanup function for end of transaction
10571052 */
10581053void
1059- AtEOXact_Snapshot (bool isCommit , bool isPrepare )
1054+ AtEOXact_Snapshot (bool isCommit )
10601055{
10611056 /*
10621057 * In transaction-snapshot mode we must release our privately-managed
@@ -1141,17 +1136,7 @@ AtEOXact_Snapshot(bool isCommit, bool isPrepare)
11411136
11421137 FirstSnapshotSet = false;
11431138
1144- /*
1145- * During normal commit and abort processing, we call
1146- * ProcArrayEndTransaction() or ProcArrayClearTransaction() to
1147- * reset the PgXact->xmin. That call happens prior to the call to
1148- * AtEOXact_Snapshot(), so we need not touch xmin here at all,
1149- * accept when we are preparing a transaction.
1150- */
1151- if (isPrepare )
1152- SnapshotResetXmin ();
1153-
1154- Assert (MyPgXact -> xmin == 0 );
1139+ SnapshotResetXmin ();
11551140}
11561141
11571142
0 commit comments