Update comments that became out-of-date with the PGXACT struct.

When the "hot" members of PGPROC were split off to separate PGXACT structs,
many PGPROC fields referred to in comments were moved to PGXACT, but the
comments were neglected in the commit. Mostly this is just a search/replace
of PGPROC with PGXACT, but the way the dummy PGPROC entries are created for
prepared transactions changed more, making some of the comments totally
bogus.

Noah Misch

src/backend/storage/ipc/procarray.c

@@ -4,18 +4,18 @@
  *	  POSTGRES process array code.
  *
  *
- * This module maintains an unsorted array of the PGPROC structures for all
+ * This module maintains arrays of the PGPROC and PGXACT structures for all
  * active backends.  Although there are several uses for this, the principal
  * one is as a means of determining the set of currently running transactions.
  *
  * Because of various subtle race conditions it is critical that a backend
- * hold the correct locks while setting or clearing its MyProc->xid field.
+ * hold the correct locks while setting or clearing its MyPgXact->xid field.
  * See notes in src/backend/access/transam/README.
  *
- * The process array now also includes PGPROC structures representing
- * prepared transactions.  The xid and subxids fields of these are valid,
- * as are the myProcLocks lists.  They can be distinguished from regular
- * backend PGPROCs at need by checking for pid == 0.
+ * The process arrays now also include structures representing prepared
+ * transactions.  The xid and subxids fields of these are valid, as are the
+ * myProcLocks lists.  They can be distinguished from regular backend PGPROCs
+ * at need by checking for pid == 0.
  *
  * During hot standby, we also keep a list of XIDs representing transactions
  * that are known to be running in the master (or more precisely, were running
@@ -75,7 +75,7 @@ typedef struct ProcArrayStruct
 	/*
 	 * Highest subxid that has been removed from KnownAssignedXids array to
 	 * prevent overflow; or InvalidTransactionId if none.  We track this for
-	 * similar reasons to tracking overflowing cached subxids in PGPROC
+	 * similar reasons to tracking overflowing cached subxids in PGXACT
 	 * entries.  Must hold exclusive ProcArrayLock to change this, and shared
 	 * lock to read it.
 	 */
@@ -440,7 +440,7 @@ ProcArrayEndTransaction(PGPROC *proc, TransactionId latestXid)
  * This is used after successfully preparing a 2-phase transaction.  We are
  * not actually reporting the transaction's XID as no longer running --- it
  * will still appear as running because the 2PC's gxact is in the ProcArray
- * too.  We just have to clear out our own PGPROC.
+ * too.  We just have to clear out our own PGXACT.
  */
 void
 ProcArrayClearTransaction(PGPROC *proc)
@@ -752,7 +752,7 @@ ProcArrayApplyXidAssignment(TransactionId topxid,
  * there are four possibilities for finding a running transaction:
  *
  * 1. The given Xid is a main transaction Id.  We will find this out cheaply
- * by looking at the PGPROC struct for each backend.
+ * by looking at the PGXACT struct for each backend.
  *
  * 2. The given Xid is one of the cached subxact Xids in the PGPROC array.
  * We can find this out cheaply too.
@@ -760,16 +760,16 @@ ProcArrayApplyXidAssignment(TransactionId topxid,
  * 3. In Hot Standby mode, we must search the KnownAssignedXids list to see
  * if the Xid is running on the master.
  *
- * 4. Search the SubTrans tree to find the Xid's topmost parent, and then
- * see if that is running according to PGPROC or KnownAssignedXids.  This is
- * the slowest way, but sadly it has to be done always if the others failed,
+ * 4. Search the SubTrans tree to find the Xid's topmost parent, and then see
+ * if that is running according to PGXACT or KnownAssignedXids.  This is the
+ * slowest way, but sadly it has to be done always if the others failed,
  * unless we see that the cached subxact sets are complete (none have
  * overflowed).
  *
  * ProcArrayLock has to be held while we do 1, 2, 3.  If we save the top Xids
  * while doing 1 and 3, we can release the ProcArrayLock while we do 4.
  * This buys back some concurrency (and we can't retrieve the main Xids from
- * PGPROC again anyway; see GetNewTransactionId).
+ * PGXACT again anyway; see GetNewTransactionId).
  */
 bool
 TransactionIdIsInProgress(TransactionId xid)
@@ -915,7 +915,7 @@ TransactionIdIsInProgress(TransactionId xid)
 	 */
 	if (RecoveryInProgress())
 	{
-		/* none of the PGPROC entries should have XIDs in hot standby mode */
+		/* none of the PGXACT entries should have XIDs in hot standby mode */
 		Assert(nxids == 0);
 
 		if (KnownAssignedXidExists(xid))
@@ -1283,7 +1283,7 @@ GetSnapshotData(Snapshot snapshot)
 
 	/*
 	 * It is sufficient to get shared lock on ProcArrayLock, even if we are
-	 * going to set MyProc->xmin.
+	 * going to set MyPgXact->xmin.
 	 */
 	LWLockAcquire(ProcArrayLock, LW_SHARED);
 
@@ -1462,7 +1462,7 @@ GetSnapshotData(Snapshot snapshot)
 }
 
 /*
- * ProcArrayInstallImportedXmin -- install imported xmin into MyProc->xmin
+ * ProcArrayInstallImportedXmin -- install imported xmin into MyPgXact->xmin
  *
  * This is called when installing a snapshot imported from another
  * transaction.  To ensure that OldestXmin doesn't go backwards, we must
@@ -1538,7 +1538,7 @@ ProcArrayInstallImportedXmin(TransactionId xmin, TransactionId sourcexid)
  * GetRunningTransactionData -- returns information about running transactions.
  *
  * Similar to GetSnapshotData but returns more information. We include
- * all PGPROCs with an assigned TransactionId, even VACUUM processes.
+ * all PGXACTs with an assigned TransactionId, even VACUUM processes.
  *
  * We acquire XidGenLock, but the caller is responsible for releasing it.
  * This ensures that no new XIDs enter the proc array until the caller has
@@ -1679,7 +1679,7 @@ GetRunningTransactionData(void)
  * GetOldestActiveTransactionId()
  *
  * Similar to GetSnapshotData but returns just oldestActiveXid. We include
- * all PGPROCs with an assigned TransactionId, even VACUUM processes.
+ * all PGXACTs with an assigned TransactionId, even VACUUM processes.
  * We look at all databases, though there is no need to include WALSender
  * since this has no effect on hot standby conflicts.
  *
@@ -1744,7 +1744,7 @@ GetOldestActiveTransactionId(void)
  * GetTransactionsInCommit -- Get the XIDs of transactions that are committing
  *
  * Constructs an array of XIDs of transactions that are currently in commit
- * critical sections, as shown by having inCommit set in their PGPROC entries.
+ * critical sections, as shown by having inCommit set in their PGXACT entries.
  *
  * *xids_p is set to a palloc'd array that should be freed by the caller.
  * The return value is the number of valid entries.
@@ -2189,7 +2189,7 @@ MinimumActiveBackends(int min)
 		 *
 		 * If someone just decremented numProcs, 'proc' could also point to a
 		 * PGPROC entry that's no longer in the array. It still points to a
-		 * PGPROC struct, though, because freed PGPPROC entries just go to the
+		 * PGPROC struct, though, because freed PGPROC entries just go to the
 		 * free list and are recycled. Its contents are nonsense in that case,
 		 * but that's acceptable for this function.
 		 */
@@ -2514,7 +2514,7 @@ DisplayXidCache(void)
  * In Hot Standby mode, we maintain a list of transactions that are (or were)
  * running in the master at the current point in WAL.  These XIDs must be
  * treated as running by standby transactions, even though they are not in
- * the standby server's PGPROC array.
+ * the standby server's PGXACT array.
  *
  * We record all XIDs that we know have been assigned.	That includes all the
  * XIDs seen in WAL records, plus all unobserved XIDs that we can deduce have