Re: strange parallel query behavior after OOM crashes
От | Tomas Vondra |
---|---|
Тема | Re: strange parallel query behavior after OOM crashes |
Дата | |
Msg-id | 62bb28b5-f691-41e0-d9e2-37a379db3055@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: strange parallel query behavior after OOM crashes (Kuntal Ghosh <kuntalghosh.2007@gmail.com>) |
Список | pgsql-hackers |
On 04/05/2017 04:15 PM, Robert Haas 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. > No, the workers were started, but are still running, so register_count = 4 terminate_count = 0 >> Backend 2> SET max_parallel_worker = 3; >> Backend 2 > Try to execute any parallel query q2 with number of >> parallel worker spawned > 0. > > Now here parallel_register_count should get bumped up to 4+(# of > workers now launched) at the beginning and then > parallel_terminate_count at the end. No problem. > > What's going wrong, here? > Well, assuming the other workers are still running, you get register_count = 4 terminate_count = 0 and the difference is greater than max_parallel_workers = 3. Which violates the assert. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: