Occasional 9.6.10 PMChildFlags fatal error, possibly due to >2parallel gathers

I have a Debian Stretch system running the 9.6.10 build from Debian APT repos. It has been running flawlessly, lightly loaded, for about a year and a half, only being restarted for security updates. It recently crashed twice about an hour apart due to postmaster receiving a signal from a worker task, both times with this complaint in the log:

FATAL:  no free slots in PMChildFlags array

For more context, I got these tightly packed around the first crash, with the first and last messages repeated hundreds of times:

The second time, I got this:

followed hundreds of lines of terminating connection later by this:

and hundreds of database start lines later by this:

Possibly of interest, the last completed transaction was 2 minutes after the last known time up.

I asked the application developers using the cluster if they had recently made any changes, and they said they had not. A Google search for the PMChildFlags error message found nothing recent. Since it seemed to be related to parallel queries, I looked up that behavior, and found a post that indicates that it'll use 3 workers if the table size is greater than 72 MB and configuration allows. We had max_parallel_workers_per_gather set at 10 for performance testing (the workload in no way needed that), so that was a possibility. I checked the sizes of tables in the cluster, and found that the table that the crashing query was accessing is 80 MB, and no other table in the cluster is that large.

My suspicion is that there's some sort of race condition that requires at least 3 parallel gather workers to hit, and most people aren't hitting it because they're not setting it that high, and there's something specific about my workload that triggers it. I think we started hitting it shortly after an autovacuum updated the query planner stats to reflect that the table was larger than 72 MB, which is why we didn't hit it at 72 MB.

Unfortunately, we didn't have more detailed timestamped logs at the time to confirm this theory, and it hasn't happened a third time. We've lowered max_parallel_workers_per_gather to 2, since this is a production system, but we may be able to rig up a reproducer with some guidance.

- Chris