Re: A new function to wait for the backend exit after termination

Поиск
Список
Период
Сортировка
От Bharath Rupireddy
Тема Re: A new function to wait for the backend exit after termination
Дата
Msg-id CALj2ACVCfa4rMu8C4h5eauHJiS5ZY3GTd6pA6fNjuo39DZ3k8A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A new function to wait for the backend exit after termination  (Noah Misch <noah@leadboat.com>)
Ответы Re: A new function to wait for the backend exit after termination  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Sat, Jun 5, 2021 at 7:02 AM Noah Misch <noah@leadboat.com> wrote:
>
> On Tue, Jun 01, 2021 at 01:25:24PM +0530, Bharath Rupireddy wrote:
> > On Tue, Jun 1, 2021 at 9:19 AM Noah Misch <noah@leadboat.com> wrote:
> > > Given that limitation, is pg_wait_for_backend_termination() useful enough?  If
> > > waiting for procarray departure is enough, should pg_wait_until_termination()
> > > check BackendPidGetProc(pid) instead of kill(0, pid), so it can return
> > > earlier?
> >
> > We can just remove BackendPidGetProc(pid) in
> > pg_wait_for_backend_termination. With this change, we can get rid of
> > the wait_pid() from regress.c. But, my concern is that the
> > pg_wait_for_backend_termination() can also check non-postgres server
> > process pid. Is this okay?
>
> It may or may not be okay.  I would not feel good about it.
>
> > In that case, this function becomes a
> > generic(OS level function) rather than a postgres server specific
> > function. I'm not sure if all agree to that. Thoughts?
>
> My preference is to remove pg_wait_for_backend_termination().  The use case
> that prompted this thread used pg_terminate_backend(pid, 180000); it doesn't
> need pg_wait_for_backend_termination().

I was earlier thinking that the function
pg_wait_for_backend_termination() will be useful:
1) If the user wants to pg_terminate_backend(<<pid>>); and
pg_wait_for_backend_termination(<<pid>>, <<timeout>>); separately. It
seems like the proc array entry will be removed as part of SITERM
processing (see [1]) and the BackendPidGetProc will return NULL. So,
it's not useful here.
2) If the user wants to pg_wait_for_backend_termination(<<pid>>,
<<timeout>>);, thinking that some event might cause the backend to be
terminated within the <<timeout>>. So, it's still useful here.

[1]
(gdb) bt
#0  ProcArrayRemove (proc=0x55b27f26356c
<CleanupInvalidationState+278>, latestXid=32764)
    at procarray.c:526
#1  0x000055b27f281c9d in RemoveProcFromArray (code=1, arg=0) at proc.c:812
#2  0x000055b27f2542ce in shmem_exit (code=1) at ipc.c:272
#3  0x000055b27f2540d5 in proc_exit_prepare (code=1) at ipc.c:194
#4  0x000055b27f254022 in proc_exit (code=1) at ipc.c:107
#5  0x000055b27f449479 in errfinish (filename=0x55b27f61cd65
"postgres.c", lineno=3191,
    funcname=0x55b27f61e770 <__func__.40727> "ProcessInterrupts") at elog.c:666
#6  0x000055b27f29097e in ProcessInterrupts () at postgres.c:3191
#7  0x000055b27f28cbf0 in ProcessClientReadInterrupt (blocked=true) at
postgres.c:499

With Regards,
Bharath Rupireddy.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Are we missing (void) when return value of fsm_set_and_search is ignored?
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: logical decoding bug: segfault in ReorderBufferToastReplace()