Re: strange parallel query behavior after OOM crashes
От | Robert Haas |
---|---|
Тема | Re: strange parallel query behavior after OOM crashes |
Дата | |
Msg-id | CA+TgmoZrC+PUpNE_V5Wm78FA9W5ReLVYWpK8HGiw3KXoc+6_QQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: strange parallel query behavior after OOM crashes (Kuntal Ghosh <kuntalghosh.2007@gmail.com>) |
Ответы |
Re: strange parallel query behavior after OOM crashes
|
Список | pgsql-hackers |
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. > 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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: