Fix the initialization of atomic variable introduced by the

group clearing mechanism.

Commit 0e141c0fbb 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[email protected]

diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
index cb6e1e3e5bc68fb4d4e7d9608decbad4268fed9f..3f80c8228873611767c41be479a72783a2dbb91b 100644 (file)
--- a/src/backend/storage/lmgr/proc.c
+++ b/src/backend/storage/lmgr/proc.c
@@ -268,6 +268,12 @@ InitProcGlobal(void)
 
        /* Initialize lockGroupMembers list. */
        dlist_init(&procs[i].lockGroupMembers);
+
+       /*
+        * Initialize the atomic variable, otherwise, it won't be safe to
+        * access it for backends that aren't currently in use.
+        */
+       pg_atomic_init_u32(&(procs[i].procArrayGroupNext), INVALID_PGPROCNO);
    }
 
    /*
@@ -401,7 +407,7 @@ InitProcess(void)
    /* Initialize fields for group XID clearing. */
    MyProc->procArrayGroupMember = false;
    MyProc->procArrayGroupMemberXid = InvalidTransactionId;
-   pg_atomic_init_u32(&MyProc->procArrayGroupNext, INVALID_PGPROCNO);
+   Assert(pg_atomic_read_u32(&MyProc->procArrayGroupNext) == INVALID_PGPROCNO);
 
    /* Check that group locking fields are in a proper initial state. */
    Assert(MyProc->lockGroupLeader == NULL);