Re: Logical replication launcher did not automatically restart when got SIGKILL
От | shveta malik |
---|---|
Тема | Re: Logical replication launcher did not automatically restart when got SIGKILL |
Дата | |
Msg-id | CAJpy0uCYPnqecJxGbpjppKmNqJqA2Ka1sbLo4Zgy6Y3_+RwpbQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical replication launcher did not automatically restart when got SIGKILL (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Logical replication launcher did not automatically restart when got SIGKILL
|
Список | pgsql-hackers |
On Fri, Jul 25, 2025 at 7:17 AM Fujii Masao <masao.fujii@gmail.com> wrote: > > On Thu, Jul 24, 2025 at 6:46 PM shveta malik <shveta.malik@gmail.com> wrote: > > Sounds reasonable. > > Thinking out loud, when cleaning up after a backend or background > > worker crash, process_pm_child_exit() is invoked, which subsequently > > calls both CleanupBackend() and HandleChildCrash(). After the cleanup > > completes, process_pm_child_exit() calls PostmasterStateMachine() to > > move to the next state. As part of that, PostmasterStateMachine() > > invokes ResetBackgroundWorkerCrashTimes() (only in crash > > scenarios/FatalError), to reset a few things. Since it also resets > > rw_worker.bgw_notify_pid, it seems reasonable to reset the rw_pid as > > well there. > > Thanks! > Attached is a patch that fixes the issue by resetting rw_pid in > ResetBackgroundWorkerCrashTimes(). > The patch LGTM. > We should probably add a regression test for this case, > but I'd prefer to commit the fix first and work on the test separately. > Andrey Rudometov proposed a test patch in thread [1], > which we might use as a starting point. Sounds good. thanks Shveta
В списке pgsql-hackers по дате отправления: