Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 1a8bde4

Browse files
author
Amit Kapila
committed
Fix the initialization of atomic variable introduced by the
group clearing mechanism. Commit 0e141c0 introduced initialization of atomic variable in InitProcess which means that it's not safe to look at it for backends that aren't currently in use. Fix that by initializing the same during postmaster startup. Reported-by: Andres Freund Author: Amit Kapila Backpatch-through: 9.6 Discussion: https://postgr.es/m/20181027104138.qmbbelopvy7cw2qv@alap3.anarazel.de
1 parent fe66fc6 commit 1a8bde4

File tree

1 file changed

+7
-1
lines changed
  • src/backend/storage/lmgr

1 file changed

+7
-1
lines changed

src/backend/storage/lmgr/proc.c

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -268,6 +268,12 @@ InitProcGlobal(void)
268268

269269
/* Initialize lockGroupMembers list. */
270270
dlist_init(&procs[i].lockGroupMembers);
271+
272+
/*
273+
* Initialize the atomic variable, otherwise, it won't be safe to
274+
* access it for backends that aren't currently in use.
275+
*/
276+
pg_atomic_init_u32(&(procs[i].procArrayGroupNext), INVALID_PGPROCNO);
271277
}
272278

273279
/*
@@ -401,7 +407,7 @@ InitProcess(void)
401407
/* Initialize fields for group XID clearing. */
402408
MyProc->procArrayGroupMember = false;
403409
MyProc->procArrayGroupMemberXid = InvalidTransactionId;
404-
pg_atomic_init_u32(&MyProc->procArrayGroupNext, INVALID_PGPROCNO);
410+
Assert(pg_atomic_read_u32(&MyProc->procArrayGroupNext) == INVALID_PGPROCNO);
405411

406412
/* Check that group locking fields are in a proper initial state. */
407413
Assert(MyProc->lockGroupLeader == NULL);

0 commit comments

Comments
 (0)