Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit9e4637b

Browse files
committed
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 thecomments were neglected in the commit. Mostly this is just a search/replaceof PGPROC with PGXACT, but the way the dummy PGPROC entries are created forprepared transactions changed more, making some of the comments totallybogus.Noah Misch
1 parent64f09ca commit9e4637b

File tree

11 files changed

+56
-66
lines changed

11 files changed

+56
-66
lines changed

‎src/backend/access/transam/README

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -251,7 +251,7 @@ enforce, and it assists with some other issues as explained below.) The
251251
implementation of this is that GetSnapshotData takes the ProcArrayLock in
252252
shared mode (so that multiple backends can take snapshots in parallel),
253253
but ProcArrayEndTransaction must take the ProcArrayLock in exclusive mode
254-
while clearingMyProc->xid at transaction end (either commit or abort).
254+
while clearingMyPgXact->xid at transaction end (either commit or abort).
255255

256256
ProcArrayEndTransaction also holds the lock while advancing the shared
257257
latestCompletedXid variable. This allows GetSnapshotData to use
@@ -275,12 +275,12 @@ present in the ProcArray, or not running anymore. (This guarantee doesn't
275275
apply to subtransaction XIDs, because of the possibility that there's not
276276
room for them in the subxid array; instead we guarantee that they are
277277
present or the overflow flag is set.) If a backend released XidGenLock
278-
before storing its XID intoMyProc, then it would be possible for another
278+
before storing its XID intoMyPgXact, then it would be possible for another
279279
backend to allocate and commit a later XID, causing latestCompletedXid to
280280
pass the first backend's XID, before that value became visible in the
281281
ProcArray. That would break GetOldestXmin, as discussed below.
282282

283-
We allow GetNewTransactionId to store the XID intoMyProc->xid (or the
283+
We allow GetNewTransactionId to store the XID intoMyPgXact->xid (or the
284284
subxid array) without taking ProcArrayLock. This was once necessary to
285285
avoid deadlock; while that is no longer the case, it's still beneficial for
286286
performance. We are thereby relying on fetch/store of an XID to be atomic,
@@ -293,7 +293,7 @@ ensure that the C compiler does exactly what you tell it to.)
293293
Another important activity that uses the shared ProcArray is GetOldestXmin,
294294
which must determine a lower bound for the oldest xmin of any active MVCC
295295
snapshot, system-wide. Each individual backend advertises the smallest
296-
xmin of its own snapshots inMyProc->xmin, or zero if it currently has no
296+
xmin of its own snapshots inMyPgXact->xmin, or zero if it currently has no
297297
live snapshots (eg, if it's between transactions or hasn't yet set a
298298
snapshot for a new transaction). GetOldestXmin takes the MIN() of the
299299
valid xmin fields. It does this with only shared lock on ProcArrayLock,
@@ -320,7 +320,7 @@ too expensive. Note that while it is certain that two concurrent
320320
executions of GetSnapshotData will compute the same xmin for their own
321321
snapshots, as argued above, it is not certain that they will arrive at the
322322
same estimate of RecentGlobalXmin. This is because we allow XID-less
323-
transactions to clear theirMyProc->xmin asynchronously (without taking
323+
transactions to clear theirMyPgXact->xmin asynchronously (without taking
324324
ProcArrayLock), so one execution might see what had been the oldest xmin,
325325
and another not. This is OK since RecentGlobalXmin need only be a valid
326326
lower bound. As noted above, we are already assuming that fetch/store
@@ -371,7 +371,7 @@ Top-level transactions do not have a parent, so they leave their pg_subtrans
371371
entries set to the default value of zero (InvalidTransactionId).
372372

373373
pg_subtrans is used to check whether the transaction in question is still
374-
running --- the main Xid of a transaction is recorded in thePGPROC struct,
374+
running --- the main Xid of a transaction is recorded in thePGXACT struct,
375375
but since we allow arbitrary nesting of subtransactions, we can't fit all Xids
376376
in shared memory, so we have to store them on disk. Note, however, that for
377377
each transaction we keep a "cache" of Xids that are known to be part of the

‎src/backend/access/transam/twophase.c

Lines changed: 6 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -21,10 +21,9 @@
2121
*GIDs and aborts the transaction if there already is a global
2222
*transaction in prepared state with the same GID.
2323
*
24-
*A global transaction (gxact) also has a dummy PGPROC that is entered
25-
*into the ProcArray array; this is what keeps the XID considered
26-
*running by TransactionIdIsInProgress. It is also convenient as a
27-
*PGPROC to hook the gxact's locks to.
24+
*A global transaction (gxact) also has dummy PGXACT and PGPROC; this is
25+
*what keeps the XID considered running by TransactionIdIsInProgress.
26+
*It is also convenient as a PGPROC to hook the gxact's locks to.
2827
*
2928
*In order to survive crashes and shutdowns, all prepared
3029
*transactions must be stored in permanent storage. This includes
@@ -79,19 +78,14 @@ intmax_prepared_xacts = 0;
7978
* This struct describes one global transaction that is in prepared state
8079
* or attempting to become prepared.
8180
*
82-
* The first component of the struct is a dummy PGPROC that is inserted
83-
* into the global ProcArray so that the transaction appears to still be
84-
* running and holding locks. It must be first because we cast pointers
85-
* to PGPROC and pointers to GlobalTransactionData back and forth.
86-
*
8781
* The lifecycle of a global transaction is:
8882
*
8983
* 1. After checking that the requested GID is not in use, set up an
9084
* entry in the TwoPhaseState->prepXacts array with the correct XID and GID,
9185
* with locking_xid = my own XID and valid = false.
9286
*
9387
* 2. After successfully completing prepare, set valid = true and enter the
94-
*contained PGPROC into the global ProcArray.
88+
*referenced PGPROC into the global ProcArray.
9589
*
9690
* 3. To begin COMMIT PREPARED or ROLLBACK PREPARED, check that the entry
9791
* is valid and its locking_xid is no longer active, then store my current
@@ -1069,12 +1063,12 @@ EndPrepare(GlobalTransaction gxact)
10691063
errmsg("could not close two-phase state file: %m")));
10701064

10711065
/*
1072-
* Mark the prepared transaction as valid.As soon as xact.c marksMyProc
1066+
* Mark the prepared transaction as valid.As soon as xact.c marksMyPgXact
10731067
* as not running our XID (which it will do immediately after this
10741068
* function returns), others can commit/rollback the xact.
10751069
*
10761070
* NB: a side effect of this is to make a dummy ProcArray entry for the
1077-
* prepared XID. This must happen before we clear the XID fromMyProc,
1071+
* prepared XID. This must happen before we clear the XID fromMyPgXact,
10781072
* else there is a window where the XID is not running according to
10791073
* TransactionIdIsInProgress, and onlookers would be entitled to assume
10801074
* the xact crashed. Instead we have a window where the same XID appears

‎src/backend/access/transam/varsup.c

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -35,7 +35,7 @@ VariableCache ShmemVariableCache = NULL;
3535
/*
3636
* Allocate the next XID for a new transaction or subtransaction.
3737
*
38-
* The new XID is also stored intoMyProc before returning.
38+
* The new XID is also stored intoMyPgXact before returning.
3939
*
4040
* Note: when this is called, we are actually already inside a valid
4141
* transaction, since XIDs are now not allocated until the transaction
@@ -174,19 +174,19 @@ GetNewTransactionId(bool isSubXact)
174174
* latestCompletedXid is present in the ProcArray, which is essential for
175175
* correct OldestXmin tracking; see src/backend/access/transam/README.
176176
*
177-
* XXX by storing xid intoMyProc without acquiring ProcArrayLock, we are
177+
* XXX by storing xid intoMyPgXact without acquiring ProcArrayLock, we are
178178
* relying on fetch/store of an xid to be atomic, else other backends
179179
* might see a partially-set xid here.But holding both locks at once
180180
* would be a nasty concurrency hit. So for now, assume atomicity.
181181
*
182-
* Note that readers ofPGPROC xid fields should be careful to fetch the
182+
* Note that readers ofPGXACT xid fields should be careful to fetch the
183183
* value only once, rather than assume they can read a value multiple
184184
* times and get the same answer each time.
185185
*
186186
* The same comments apply to the subxact xid count and overflow fields.
187187
*
188-
* A solution to the atomic-store problem would be to give eachPGPROC its
189-
* own spinlock used only for fetching/storing thatPGPROC's xid and
188+
* A solution to the atomic-store problem would be to give eachPGXACT its
189+
* own spinlock used only for fetching/storing thatPGXACT's xid and
190190
* related fields.
191191
*
192192
* If there's no room to fit a subtransaction XID into PGPROC, set the

‎src/backend/commands/analyze.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -279,7 +279,7 @@ analyze_rel(Oid relid, VacuumStmt *vacstmt, BufferAccessStrategy bstrategy)
279279
relation_close(onerel,NoLock);
280280

281281
/*
282-
* Reset myPGPROC flag. Note: we need this here, and not in vacuum_rel,
282+
* Reset myPGXACT flag. Note: we need this here, and not in vacuum_rel,
283283
* because the vacuum flag is cleared by the end-of-xact code.
284284
*/
285285
LWLockAcquire(ProcArrayLock,LW_EXCLUSIVE);

‎src/backend/commands/vacuum.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -892,7 +892,7 @@ vacuum_rel(Oid relid, VacuumStmt *vacstmt, bool do_toast, bool for_wraparound)
892892
*
893893
* Note: these flags remain set until CommitTransaction or
894894
* AbortTransaction. We don't want to clear them until we reset
895-
*MyProc->xid/xmin, else OldestXmin might appear to go backwards,
895+
*MyPgXact->xid/xmin, else OldestXmin might appear to go backwards,
896896
* which is probably Not Good.
897897
*/
898898
LWLockAcquire(ProcArrayLock,LW_EXCLUSIVE);

‎src/backend/postmaster/autovacuum.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2327,7 +2327,7 @@ do_autovacuum(void)
23272327
tab->at_datname,tab->at_nspname,tab->at_relname);
23282328
EmitErrorReport();
23292329

2330-
/* this resets thePGPROC flags too */
2330+
/* this resets thePGXACT flags too */
23312331
AbortOutOfAnyTransaction();
23322332
FlushErrorState();
23332333
MemoryContextResetAndDeleteChildren(PortalContext);
@@ -2338,7 +2338,7 @@ do_autovacuum(void)
23382338
}
23392339
PG_END_TRY();
23402340

2341-
/* thePGPROC flags are reset at the next end of transaction */
2341+
/* thePGXACT flags are reset at the next end of transaction */
23422342

23432343
/* be tidy */
23442344
deleted:

‎src/backend/storage/ipc/procarray.c

Lines changed: 21 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -4,18 +4,18 @@
44
* POSTGRES process array code.
55
*
66
*
7-
* This module maintainsan unsorted arrayof the PGPROC structures for all
7+
* This module maintainsarraysof the PGPROC and PGXACT structures for all
88
* active backends. Although there are several uses for this, the principal
99
* one is as a means of determining the set of currently running transactions.
1010
*
1111
* Because of various subtle race conditions it is critical that a backend
12-
* hold the correct locks while setting or clearing itsMyProc->xid field.
12+
* hold the correct locks while setting or clearing itsMyPgXact->xid field.
1313
* See notes in src/backend/access/transam/README.
1414
*
15-
* The processarray now alsoincludes PGPROCstructures representing
16-
*preparedtransactions. The xid and subxids fields of these are valid,
17-
*as are themyProcLocks lists. They can be distinguished from regular
18-
*backend PGPROCsat need by checking for pid == 0.
15+
* The processarrays now alsoincludestructures representing prepared
16+
* transactions. The xid and subxids fields of these are valid, as are the
17+
* myProcLocks lists. They can be distinguished from regular backend PGPROCs
18+
* at need by checking for pid == 0.
1919
*
2020
* During hot standby, we also keep a list of XIDs representing transactions
2121
* that are known to be running in the master (or more precisely, were running
@@ -75,7 +75,7 @@ typedef struct ProcArrayStruct
7575
/*
7676
* Highest subxid that has been removed from KnownAssignedXids array to
7777
* prevent overflow; or InvalidTransactionId if none. We track this for
78-
* similar reasons to tracking overflowing cached subxids inPGPROC
78+
* similar reasons to tracking overflowing cached subxids inPGXACT
7979
* entries. Must hold exclusive ProcArrayLock to change this, and shared
8080
* lock to read it.
8181
*/
@@ -440,7 +440,7 @@ ProcArrayEndTransaction(PGPROC *proc, TransactionId latestXid)
440440
* This is used after successfully preparing a 2-phase transaction. We are
441441
* not actually reporting the transaction's XID as no longer running --- it
442442
* will still appear as running because the 2PC's gxact is in the ProcArray
443-
* too. We just have to clear out our ownPGPROC.
443+
* too. We just have to clear out our ownPGXACT.
444444
*/
445445
void
446446
ProcArrayClearTransaction(PGPROC*proc)
@@ -752,24 +752,24 @@ ProcArrayApplyXidAssignment(TransactionId topxid,
752752
* there are four possibilities for finding a running transaction:
753753
*
754754
* 1. The given Xid is a main transaction Id. We will find this out cheaply
755-
* by looking at thePGPROC struct for each backend.
755+
* by looking at thePGXACT struct for each backend.
756756
*
757757
* 2. The given Xid is one of the cached subxact Xids in the PGPROC array.
758758
* We can find this out cheaply too.
759759
*
760760
* 3. In Hot Standby mode, we must search the KnownAssignedXids list to see
761761
* if the Xid is running on the master.
762762
*
763-
* 4. Search the SubTrans tree to find the Xid's topmost parent, and then
764-
*seeif that is running according toPGPROC or KnownAssignedXids. This is
765-
*theslowest way, but sadly it has to be done always if the others failed,
763+
* 4. Search the SubTrans tree to find the Xid's topmost parent, and then see
764+
* if that is running according toPGXACT or KnownAssignedXids. This is the
765+
* slowest way, but sadly it has to be done always if the others failed,
766766
* unless we see that the cached subxact sets are complete (none have
767767
* overflowed).
768768
*
769769
* ProcArrayLock has to be held while we do 1, 2, 3. If we save the top Xids
770770
* while doing 1 and 3, we can release the ProcArrayLock while we do 4.
771771
* This buys back some concurrency (and we can't retrieve the main Xids from
772-
*PGPROC again anyway; see GetNewTransactionId).
772+
*PGXACT again anyway; see GetNewTransactionId).
773773
*/
774774
bool
775775
TransactionIdIsInProgress(TransactionIdxid)
@@ -915,7 +915,7 @@ TransactionIdIsInProgress(TransactionId xid)
915915
*/
916916
if (RecoveryInProgress())
917917
{
918-
/* none of thePGPROC entries should have XIDs in hot standby mode */
918+
/* none of thePGXACT entries should have XIDs in hot standby mode */
919919
Assert(nxids==0);
920920

921921
if (KnownAssignedXidExists(xid))
@@ -1283,7 +1283,7 @@ GetSnapshotData(Snapshot snapshot)
12831283

12841284
/*
12851285
* It is sufficient to get shared lock on ProcArrayLock, even if we are
1286-
* going to setMyProc->xmin.
1286+
* going to setMyPgXact->xmin.
12871287
*/
12881288
LWLockAcquire(ProcArrayLock,LW_SHARED);
12891289

@@ -1462,7 +1462,7 @@ GetSnapshotData(Snapshot snapshot)
14621462
}
14631463

14641464
/*
1465-
* ProcArrayInstallImportedXmin -- install imported xmin intoMyProc->xmin
1465+
* ProcArrayInstallImportedXmin -- install imported xmin intoMyPgXact->xmin
14661466
*
14671467
* This is called when installing a snapshot imported from another
14681468
* transaction. To ensure that OldestXmin doesn't go backwards, we must
@@ -1538,7 +1538,7 @@ ProcArrayInstallImportedXmin(TransactionId xmin, TransactionId sourcexid)
15381538
* GetRunningTransactionData -- returns information about running transactions.
15391539
*
15401540
* Similar to GetSnapshotData but returns more information. We include
1541-
* allPGPROCs with an assigned TransactionId, even VACUUM processes.
1541+
* allPGXACTs with an assigned TransactionId, even VACUUM processes.
15421542
*
15431543
* We acquire XidGenLock, but the caller is responsible for releasing it.
15441544
* This ensures that no new XIDs enter the proc array until the caller has
@@ -1679,7 +1679,7 @@ GetRunningTransactionData(void)
16791679
* GetOldestActiveTransactionId()
16801680
*
16811681
* Similar to GetSnapshotData but returns just oldestActiveXid. We include
1682-
* allPGPROCs with an assigned TransactionId, even VACUUM processes.
1682+
* allPGXACTs with an assigned TransactionId, even VACUUM processes.
16831683
* We look at all databases, though there is no need to include WALSender
16841684
* since this has no effect on hot standby conflicts.
16851685
*
@@ -1744,7 +1744,7 @@ GetOldestActiveTransactionId(void)
17441744
* GetTransactionsInCommit -- Get the XIDs of transactions that are committing
17451745
*
17461746
* Constructs an array of XIDs of transactions that are currently in commit
1747-
* critical sections, as shown by having inCommit set in theirPGPROC entries.
1747+
* critical sections, as shown by having inCommit set in theirPGXACT entries.
17481748
*
17491749
* *xids_p is set to a palloc'd array that should be freed by the caller.
17501750
* The return value is the number of valid entries.
@@ -2189,7 +2189,7 @@ MinimumActiveBackends(int min)
21892189
*
21902190
* If someone just decremented numProcs, 'proc' could also point to a
21912191
* PGPROC entry that's no longer in the array. It still points to a
2192-
* PGPROC struct, though, because freedPGPPROC entries just go to the
2192+
* PGPROC struct, though, because freedPGPROC entries just go to the
21932193
* free list and are recycled. Its contents are nonsense in that case,
21942194
* but that's acceptable for this function.
21952195
*/
@@ -2514,7 +2514,7 @@ DisplayXidCache(void)
25142514
* In Hot Standby mode, we maintain a list of transactions that are (or were)
25152515
* running in the master at the current point in WAL. These XIDs must be
25162516
* treated as running by standby transactions, even though they are not in
2517-
* the standby server'sPGPROC array.
2517+
* the standby server'sPGXACT array.
25182518
*
25192519
* We record all XIDs that we know have been assigned.That includes all the
25202520
* XIDs seen in WAL records, plus all unobserved XIDs that we can deduce have

‎src/backend/storage/lmgr/proc.c

Lines changed: 7 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -56,7 +56,7 @@ intDeadlockTimeout = 1000;
5656
intStatementTimeout=0;
5757
boollog_lock_waits= false;
5858

59-
/* Pointer to this process's PGPROCstruct, if any */
59+
/* Pointer to this process's PGPROCand PGXACT structs, if any */
6060
PGPROC*MyProc=NULL;
6161
PGXACT*MyPgXact=NULL;
6262

@@ -190,15 +190,11 @@ InitProcGlobal(void)
190190
ProcGlobal->checkpointerLatch=NULL;
191191

192192
/*
193-
* Create and initialize all the PGPROC structures we'll need (except for
194-
* those used for 2PC, which are embedded within a GlobalTransactionData
195-
* struct).
196-
*
197-
* There are four separate consumers of PGPROC structures: (1) normal
198-
* backends, (2) autovacuum workers and the autovacuum launcher, (3)
199-
* auxiliary processes, and (4) prepared transactions. Each PGPROC
200-
* structure is dedicated to exactly one of these purposes, and they do
201-
* not move between groups.
193+
* Create and initialize all the PGPROC structures we'll need. There are
194+
* four separate consumers: (1) normal backends, (2) autovacuum workers
195+
* and the autovacuum launcher, (3) auxiliary processes, and (4) prepared
196+
* transactions. Each PGPROC structure is dedicated to exactly one of
197+
* these purposes, and they do not move between groups.
202198
*/
203199
procs= (PGPROC*)ShmemAlloc(TotalProcs*sizeof(PGPROC));
204200
ProcGlobal->allProcs=procs;
@@ -214,7 +210,7 @@ InitProcGlobal(void)
214210
* from the main PGPROC array so that the most heavily accessed data is
215211
* stored contiguously in memory in as few cache lines as possible. This
216212
* provides significant performance benefits, especially on a
217-
* multiprocessor system.Thereis one PGXACT structure for every PGPROC
213+
* multiprocessor system.There is one PGXACT structure for every PGPROC
218214
* structure.
219215
*/
220216
pgxacts= (PGXACT*)ShmemAlloc(TotalProcs*sizeof(PGXACT));

‎src/backend/utils/time/snapmgr.c

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,7 @@
1919
* have regd_count = 1 and are counted in RegisteredSnapshots, but are not
2020
* tracked by any resource owner.
2121
*
22-
* These arrangements let us resetMyProc->xmin when there are no snapshots
22+
* These arrangements let us resetMyPgXact->xmin when there are no snapshots
2323
* referenced by this transaction.(One possible improvement would be to be
2424
* able to advance Xmin when the snapshot with the earliest Xmin is no longer
2525
* referenced.That's a bit harder though, it requires more locking, and
@@ -104,7 +104,7 @@ static ActiveSnapshotElt *ActiveSnapshot = NULL;
104104
* How many snapshots is resowner.c tracking for us?
105105
*
106106
* Note: for now, a simple counter is enough. However, if we ever want to be
107-
* smarter about advancing ourMyProc->xmin we will need to be more
107+
* smarter about advancing ourMyPgXact->xmin we will need to be more
108108
* sophisticated about this, perhaps keeping our own list of snapshots.
109109
*/
110110
staticintRegisteredSnapshots=0;
@@ -266,7 +266,7 @@ SetTransactionSnapshot(Snapshot sourcesnap, TransactionId sourcexid)
266266
/* NB: curcid should NOT be copied, it's a local matter */
267267

268268
/*
269-
* Now we have to fix what GetSnapshotData did withMyProc->xmin and
269+
* Now we have to fix what GetSnapshotData did withMyPgXact->xmin and
270270
* TransactionXmin. There is a race condition: to make sure we are not
271271
* causing the global xmin to go backwards, we have to test that the
272272
* source transaction is still running, and that has to be done atomically.
@@ -569,7 +569,7 @@ UnregisterSnapshotFromOwner(Snapshot snapshot, ResourceOwner owner)
569569
/*
570570
* SnapshotResetXmin
571571
*
572-
* If there are no more snapshots, we can reset ourPGPROC->xmin to InvalidXid.
572+
* If there are no more snapshots, we can reset ourPGXACT->xmin to InvalidXid.
573573
* Note we can do this without locking because we assume that storing an Xid
574574
* is atomic.
575575
*/

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp