Re: Parallel bt build crashes when DSM_NONE

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: Parallel bt build crashes when DSM_NONE
Date: 2018-02-12 13:05:36
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Feb 09, 2018 at 05:06:35PM +0900, Kyotaro HORIGUCHI wrote:
> I happend to find that server crashes during regtest when
> DSM_NONE is enforced. The attached patch fixes that.
> The cause is the fact that _bt_spools_heapscan runs
> _bt_begin_parallel() even if dynamic_shared_memory_type is
> DSM_NONE. It is because plan_create_index_workers() is ignoring
> dynamic_shared_memory_type.

Adding Peter Geoghegan as the author and Robert as the committer in CC,
as that's a mistake from 9da0cc35.

> We can reproduce this by letting initdb set
> dynamic_shared_memory_type=none regardless of actual
> availability. (Second attached) and just "make check".

Or more simply you can just setup an instance with this configuration
and run installcheck. No need to patch initdb for that.

4 regression tests fail when using dynamic_shared_memory_type=none:
join, aggregates, select_parallel and write_parallel. test_shm_mq of
course blows up. Could that justify getting rid of DSM_IMPL_NONE? As
far as I can see there is an alternative on Windows, and we fallback to
sysv in the worst case. So I am wondering what's actually the use case
for "none". And it is good to keep alternate outputs at a minimum,
those tend to rot easily.

Except for those mind errands your patch looks good to me.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-02-12 13:28:15 Re: Server won't start with fallback setting by initdb.
Previous Message Rajkumar Raghuwanshi 2018-02-12 12:30:24 Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.