Re: strange parallel query behavior after OOM crashes
Kuntal Ghosh <kuntalghosh.2007@gmail.com>
From: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Robert Haas <robertmhaas@gmail.com>
Date: 2017-03-30T21:29:55Z
Lists: pgsql-hackers
Attachments
- fix-workers-launched.patch (binary/octet-stream) patch
On Fri, Mar 31, 2017 at 2:05 AM, Kuntal Ghosh <kuntalghosh.2007@gmail.com> wrote: > > 1. Put an Assert(0) in ParallelQueryMain(), start server and execute > any parallel query. > In LaunchParallelWorkers, you can see > nworkers = n nworkers_launched = n (n>0) > But, all the workers will crash because of the assert statement. > 2. the server restarts automatically, initialize > BackgroundWorkerData->parallel_register_count and > BackgroundWorkerData->parallel_terminate_count in the shared memory. > After that, it calls ForgetBackgroundWorker and it increments > parallel_terminate_count. In LaunchParallelWorkers, we have the > following condition: > if ((BackgroundWorkerData->parallel_register_count - > BackgroundWorkerData->parallel_terminate_count) >= > max_parallel_workers) > DO NOT launch any parallel worker. > Hence, nworkers = n nworkers_launched = 0. parallel_register_count and parallel_terminate_count, both are unsigned integer. So, whenever the difference is negative, it'll be a well-defined unsigned integer and certainly much larger than max_parallel_workers. Hence, no workers will be launched. I've attached a patch to fix this. -- 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