sorry, the message was sent out to early.
So, the issue occurs only on production db an right now I cannot reproduce it.
I had a look at dmesg and indeed I see something like:
postgres[30667]: segfault at 0 ip 0000557834264b16 sp 00007ffc2ce1e030 error 4 in postgres[557833db7000+6d5000]
and AFAIR other sessions I had opened at that time were indeed disconnected.
When it comes to the execution plan for max_parallel_workers=0.
There is no real difference.
I guess max_parallel_workers has no effect and max_parallel_workers_per_gather should have been used.
Why it caused a server crash is unknown right now.
I cannot really give a reproducible recipe.
My case is that I have a parent table with ~300 partitions.
And I initiate a select on ~100 of them with select [...] from fa where client_id(<IDS>) and [filters].
I know this is not effective. Every partition has several indexes and this query acquires a lot of locks... even for relations not used in the query.
PG11 should have better partition pruning mechanism but I'm not there yet to upgrade.
Some of the partitions have millions of rows.
I'll keep observing maybe I'l find a pattern when this occurs.
--
regards,
pozdrawiam,
Jakub Glapa
