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

Commit cce1ecf

Browse files
committed
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 e9baa5e, the slightly incorrect check didn't matter, but now it does. A test case added by commit 1804284 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
1 parent 6719b23 commit cce1ecf

File tree

1 file changed

+3
-3
lines changed
  • src/backend/access/transam

1 file changed

+3
-3
lines changed

src/backend/access/transam/xact.c

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -683,12 +683,12 @@ GetCurrentCommandId(bool used)
683683
if (used)
684684
{
685685
/*
686-
* Forbid setting currentCommandIdUsed in parallel mode, because we
687-
* have no provision for communicating this back to the master. We
686+
* Forbid setting currentCommandIdUsed in a parallel worker, because
687+
* we have no provision for communicating this back to the master. We
688688
* could relax this restriction when currentCommandIdUsed was already
689689
* true at the start of the parallel operation.
690690
*/
691-
Assert(CurrentTransactionState->parallelModeLevel == 0);
691+
Assert(!IsParallelWorker());
692692
currentCommandIdUsed = true;
693693
}
694694
return currentCommandId;

0 commit comments

Comments
 (0)