On Sat, Jun 05, 2021 at 12:06:46PM +0530, Bharath Rupireddy wrote: > On Sat, Jun 5, 2021 at 7:02 AM Noah Misch <n...@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 <n...@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.
That is factual. That pg_wait_for_backend_termination() appears to be useful for (1) but isn't useful for (1) reduces its value. I think it reduces the value slightly below zero. Relevant to that, if a user doesn't care about the distinction between "backend has left the procarray" and "backend's PID has left the kernel process table", that user can poll pg_stat_activity to achieve the same level of certainty that pg_wait_for_backend_termination() offers.
