Adjust assertion in GetCurrentCommandId.

currentCommandIdUsed is only used to skip redundant increments of the
command counter, and CommandCounterIncrement() is categorically denied
under parallelism anyway.  Therefore, it's OK for
GetCurrentCommandId() to mark the counter value used, as long as it
happens in the leader, not a worker.

Prior to commit e9baa5e9fa147e00a2466ab2c40eb99c8a700824, the slightly
incorrect check didn't matter, but now it does.  A test case added by
commit 1804284042e659e7d16904e7bbb0ad546394b6a3 uncovered the problem
by accident; it caused failures with force_parallel_mode=on/regress.

Report and review by Andres Freund.  Patch by me.

Discussion: http://postgr.es/m/20171221143106.5lhtygohvmazli3x@alap3.anarazel.de

diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index d430e662e6763411f198e3e32bbd09aec585f0db..b37510c24fb9ba95e243061668c82c4cf29d47cf 100644 (file)
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -683,12 +683,12 @@ GetCurrentCommandId(bool used)
        if (used)
        {
                /*
-                * Forbid setting currentCommandIdUsed in parallel mode, because we
-                * have no provision for communicating this back to the master.  We
+                * Forbid setting currentCommandIdUsed in a parallel worker, because
+                * we have no provision for communicating this back to the master.  We
                 * could relax this restriction when currentCommandIdUsed was already
                 * true at the start of the parallel operation.
                 */
-               Assert(CurrentTransactionState->parallelModeLevel == 0);
+               Assert(!IsParallelWorker());
                currentCommandIdUsed = true;
        }
        return currentCommandId;