Re: strange parallel query behavior after OOM crashes

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-04-05T14:15:23Z
Lists: 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


Commits

  1. Add an Assert() to max_parallel_workers enforcement.

  2. Fix confusion of max_parallel_workers mechanism following crash.

  3. Add max_parallel_workers GUC.