Re: strange parallel query behavior after OOM crashes
От | Kuntal Ghosh |
---|---|
Тема | Re: strange parallel query behavior after OOM crashes |
Дата | |
Msg-id | CAGz5QCKZOhqe31Rm3yfT6Z168js-KzKhDiGJZbUWou0TC2E9TA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: strange parallel query behavior after OOM crashes (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: strange parallel query behavior after OOM crashes
|
Список | pgsql-hackers |
On Wed, Apr 5, 2017 at 7:45 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Apr 5, 2017 at 10:09 AM, Kuntal Ghosh > <kuntalghosh.2007@gmail.com> wrote: >>> Did you intend to attach that patch to this email? >>> >> Actually, I'm confused how we should ensure (register_count > >> terminate_count) invariant. I think there can be a system crash what >> Tomas has suggested up in the thread. >> >> Assert(parallel_register_count - parallel_terminate_count <= >> max_parallel_workers); >> Backend 1 > SET max_parallel_worker = 8; >> Backend 1 > Execute a long running parallel query q1 with number of >> parallel worker spawned is say, 4. > > At this point, parallel_register_count should be equal to > parallel_terminate_count. 4 workers were started, and 4 have > terminated. > Actually, I'm referring to the case when q1 is still running. In that case, parallel_register_count = 4 and parallel_terminate_count = 0. >> Backend 2> SET max_parallel_worker = 3; Now, parallel_register_count - parallel_terminate_count = 4 > max_parallel_worker. >> Backend 2 > Try to execute any parallel query q2 with number of >> parallel worker spawned > 0. > Hence, the assert will fail here. -- Thanks & Regards, Kuntal Ghosh EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: