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

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Muhammad Usama <m(dot)usama(at)gmail(dot)com>
Subject: Re: A new function to wait for the backend exit after termination
Date: 2021-06-05 06:36:46
Message-ID: CALj2ACVCfa4rMu8C4h5eauHJiS5ZY3GTd6pA6fNjuo39DZ3k8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jun 5, 2021 at 7:02 AM Noah Misch <noah(at)leadboat(dot)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(at)leadboat(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-06-05 06:42:49 Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Previous Message Noah Misch 2021-06-05 06:05:55 Re: libpq debug log