Re: strange parallel query behavior after OOM crashes - Mailing list pgsql-hackers

From Robert Haas
Subject Re: strange parallel query behavior after OOM crashes
Date
Msg-id CA+TgmoZrC+PUpNE_V5Wm78FA9W5ReLVYWpK8HGiw3KXoc+6_QQ@mail.gmail.com
Whole thread Raw
In response to Re: strange parallel query behavior after OOM crashes  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
Responses Re: strange parallel query behavior after OOM crashes  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rewriting the test of pg_upgrade as a TAP test
Next
From: Robert Haas
Date:
Subject: Re: [sqlsmith] Unpinning error in parallel worker