Thanks for the test case! It looks like this issue is somewhat related to the "enable_incremental_sort changes query behavior" thread [1]. What I see happening is
1. The SELECT DISTINCT gives rise to a sort key expression that contains non-parallel-safe SubPlans. (It's not immediately apparent to me why we don't consider these particular subqueries parallel safe, but they aren't. Anyway such a situation surely has to be allowed for.)
2. The planner ignores the fact that the sort key isn't parallel-safe and makes a plan with IncrementalSort below Gather anyway. (I'm not certain that this bug is specific to IncrementalSort; but given the lack of previous complaints, I'm guessing we avoid this somehow for regular sorts.)
3. ExecSerializePlan notes that the subplans aren't parallel-safe and doesn't send them to the workers.
4. In the workers, nodeSubplan.c dumps core because the planstate it's expecting is not there.
So, not only do we need to be thinking about volatility while checking whether IncrementalSort is possible, but also parallel-safety.
In the meantime, now that I've seen this I don't have a lot of confidence that we'll never inject similar bugs in future. I'm thinking of committing the attached to at least reduce the stakes from "core dump" to "weird error message".
regards, tom lane
Thanks for confirming it. For now, disabling incremental sort will 'solve' the issue. I'll be keeping an eye on that thread.