> 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.
