Re: Parallel bt build crashes when DSM_NONE
От | Michael Paquier |
---|---|
Тема | Re: Parallel bt build crashes when DSM_NONE |
Дата | |
Msg-id | 20180212130536.GA18625@paquier.xyz обсуждение исходный текст |
Ответ на | Parallel bt build crashes when DSM_NONE (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Parallel bt build crashes when DSM_NONE
|
Список | 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. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: