Re: [HACKERS] strange parallel query behavior after OOM crashes
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] strange parallel query behavior after OOM crashes |
Дата | |
Msg-id | CA+TgmoZ2DEnv91mjLGvpMeiy5RSP+Rs_bmrKF_Ear1On8Tqgnw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] strange parallel query behavior after OOM crashes (Neha Khatri <nehakhatri5@gmail.com>) |
Ответы |
Re: [HACKERS] strange parallel query behavior after OOM crashes
|
Список | 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 по дате отправления: