Re: [HACKERS] strange parallel query behavior after OOM crashes - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] strange parallel query behavior after OOM crashes
Date
Msg-id CA+TgmoZ2DEnv91mjLGvpMeiy5RSP+Rs_bmrKF_Ear1On8Tqgnw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] strange parallel query behavior after OOM crashes  (Neha Khatri <nehakhatri5@gmail.com>)
Responses Re: [HACKERS] strange parallel query behavior after OOM crashes  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
List pgsql-hackers
On Mon, Apr 10, 2017 at 2:32 PM, Neha Khatri <nehakhatri5@gmail.com> wrote:
> 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;
> }
>                      ......
>                 }

Well, as noted before, not every background worker failure leads to a
crash-and-restart; for example, a non-shmem-connected worker or one
that exits with status 1 will set rw_crashed_at but will not cause a
crash-and-restart cycle.   It's not 100% clear to me whether the code
you're talking about can be reached in those cases, but I wouldn't bet
against it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] "left shift of negative value" warnings
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Some thoughts about SCRAM implementation