Re: strange parallel query behavior after OOM crashes
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Kuntal Ghosh <kuntalghosh.2007@gmail.com>,
Neha Khatri <nehakhatri5@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-04-11T16:15:55Z
Lists: pgsql-hackers
On Mon, Apr 10, 2017 at 7:17 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> At first I was like 'WTF? Why do we need a new GUC just becase of an
> assert?' but you're actually not adding a new GUC parameter, you're adding a
> constant which is then used as a max value for max for the two existing
> parallel GUCs.
>
> I think this is fine.
I think it is pretty odd-looking. As written, it computes an unsigned
-- and therefore necessarily non-negative -- value into a signed --
and thus possibly neative -- value only to pass it back to abs() to
make sure it's not negative:
+ Assert(!parallel ||
abs((int)(BackgroundWorkerData->parallel_register_count -
+
BackgroundWorkerData->parallel_terminate_count)) <=
+ MAX_PARALLEL_WORKER_LIMIT);
I think we can just say
Assert(!parallel || BackgroundWorkerData->parallel_register_count -
BackgroundWorkerData->parallel_terminate_count <= MAX_PARALLEL_WORKER_LIMIT);
--
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