Hi,
On 2017-12-05 23:01:59 -0500, Tom Lane wrote:
> I conclude that the reason we don't see the crash except on the slowest
> buildfarm critters is that on most machines the leader process manages
> to finish off all the subplans before any of the workers get as far as
> doing something. This doesn't give me a warm fuzzy feeling about how
> much testing this patch has gotten.
If that's the case, it should be reproducible on fast machines if one
sets parallel_leader_participation = off during an installcheck. Which
indeed crashes here, albeit on a heavily modified tree:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f4c05afb19a in __GI_abort () at abort.c:89
#2 0x000055d89651e83a in ExceptionalCondition (conditionName=0x55d8966edef8 "!(append->first_partial_plan <
node->as_nplans)",
errorType=0x55d8966edd86 "FailedAssertion", fileName=0x55d8966eddd8
"/home/andres/src/postgresql/src/backend/executor/nodeAppend.c",
lineNumber=503) at /home/andres/src/postgresql/src/backend/utils/error/assert.c:54
#3 0x000055d8961eab63 in choose_next_subplan_for_worker (node=0x55d8974535a0)
at /home/andres/src/postgresql/src/backend/executor/nodeAppend.c:503
#4 0x000055d8961ea47b in ExecAppend (pstate=0x55d8974535a0) at
/home/andres/src/postgresql/src/backend/executor/nodeAppend.c:216
#5 0x000055d8961d6c55 in ExecProcNode (node=0x55d8974535a0) at
/home/andres/src/postgresql/src/include/executor/executor.h:239
Greetings,
Andres Freund