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

On Wed, Oct 28, 2020 at 10:14 PM Bharath Rupireddy <
bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:

> On Wed, Oct 28, 2020 at 7:51 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> > I was thinking this would be useful for orchestration. However, as you
> say, its a pretty fragile method. I withdraw the suggestion.
> >
>
> So, pg_wait_backend(pid, timeout) waits until the backend with a given
> pid is terminated?
>
>
Yes. The original proposal.

> >
> >What I would replace it with is a pg_wait_for_notify(payload_test)
> function that allows an SQL user to plug itself into the listen/notify
> feature and pause the session until a notification arrives. The session it
> is coordinating with would >simply notify just before ending its
> script/transaction.
> >
>
> Why does one session need to listen and wait until another session
> notifies? If my understanding is wrong, could you please elaborate on
> the above point, the usage and the use case?
>

Theory, but I imagine writing an isolation test like test script where the
two sessions wait for notifications instead of sleep for random amounts of
time.

More generally, psql is very powerful but doesn't allow scripting to plug
into pub/sub. I don't have a concrete use case for why it should but the
capability doesn't seem far-fetched.

I'm not saying this is something that is needed, rather it would seem more
useful than wait_for_idle.

David J.