Horton

Re: strange parallel query behavior after OOM crashes

Neha Khatri <nehakhatri5@gmail.com>

View thread View on postgr.es
From: Neha Khatri <nehakhatri5@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kuntal Ghosh <kuntalghosh.2007@gmail.com>, Julien Rouhaud <julien.rouhaud@dalibo.com>, Amit Kapila <amit.kapila16@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-04-10T18:32:52Z
Lists: pgsql-hackers 
On Tue, Apr 11, 2017 at 1:16 AM, Robert Haas <robertmhaas@gmail.com> wrote:

>
> 1. Forget BGW_NEVER_RESTART workers in
> ResetBackgroundWorkerCrashTimes() rather than leaving them around to
> be cleaned up after the conclusion of the restart, so that they go
> away before rather than after shared memory is reset.


Now with this, would it still be required to forget BGW_NEVER_RESTART
workers in maybe_start_bgworker():

                if (rw->rw_crashed_at != 0)
{
if (rw->rw_worker.bgw_restart_time == BGW_NEVER_RESTART)
{
ForgetBackgroundWorker(&iter);
continue;
}
                     ......
                }

Regards,
Neha

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.