Re: strange parallel query behavior after OOM crashes
Kuntal Ghosh <kuntalghosh.2007@gmail.com>
From: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
To: Robert Haas <robertmhaas@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:26:31Z
Lists: pgsql-hackers
On Wed, Apr 5, 2017 at 7:45 PM, Robert Haas <robertmhaas@gmail.com> 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. > Actually, I'm referring to the case when q1 is still running. In that case, parallel_register_count = 4 and parallel_terminate_count = 0. >> Backend 2> SET max_parallel_worker = 3; Now, parallel_register_count - parallel_terminate_count = 4 > max_parallel_worker. >> Backend 2 > Try to execute any parallel query q2 with number of >> parallel worker spawned > 0. > Hence, the assert will fail here. -- Thanks & Regards, Kuntal Ghosh EnterpriseDB: http://www.enterprisedb.com
Commits
-
Add an Assert() to max_parallel_workers enforcement.
- 6599c9ac3340 10.0 landed
-
Fix confusion of max_parallel_workers mechanism following crash.
- 8ff518699f19 10.0 landed
-
Add max_parallel_workers GUC.
- b460f5d66931 10.0 cited