Re: crashes due to setting max_parallel_workers=0
От | Amit Kapila |
---|---|
Тема | Re: crashes due to setting max_parallel_workers=0 |
Дата | |
Msg-id | CAA4eK1LS1ogXxsTyqG40tHoWookfgJJricaV1ro2u1EmkTmnDA@mail.gmail.com обсуждение исходный текст |
Ответ на | crashes due to setting max_parallel_workers=0 (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: crashes due to setting max_parallel_workers=0
|
Список | pgsql-hackers |
On Sat, Mar 25, 2017 at 6:31 PM, David Rowley <david.rowley@2ndquadrant.com> wrote: > On 25 March 2017 at 23:09, Rushabh Lathia <rushabh.lathia@gmail.com> wrote: >> Also another point which I think we should fix is, when someone set >> max_parallel_workers = 0, we should also set the >> max_parallel_workers_per_gather >> to zero. So that way it we can avoid generating the gather path with >> max_parallel_worker = 0. > > I see that it was actually quite useful that it works the way it does. > If it had worked the same as max_parallel_workers_per_gather, then > likely Tomas would never have found this bug. > > I wondered if there's anything we can do here to better test cases > when no workers are able to try to ensure the parallel nodes work > correctly, but the more I think about it, the more I don't see wrong > with just using SET max_parallel_workers = 0; > > My vote would be to leave the GUC behaviour as is and add some tests > to select_parallel.sql which exploit setting max_parallel_workers to 0 > for running some tests. > I think force_parallel_mode=regress should test the same thing. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: