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
-
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