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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Rewriting the test of pg_upgrade as a TAP test
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [sqlsmith] Unpinning error in parallel worker