Re: A new function to wait for the backend exit after termination
| От | David G. Johnston |
|---|---|
| Тема | Re: A new function to wait for the backend exit after termination |
| Дата | |
| Msg-id | CAKFQuwaiHTtDJu4ES3J4d8sWJkBi5ifs_RRpNdVVsMWVwF6u6w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: A new function to wait for the backend exit after termination (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
| Список | pgsql-hackers |
On Wed, Oct 28, 2020 at 10:14 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote:
On Wed, Oct 28, 2020 at 7:51 PM David G. Johnston
<david.g.johnston@gmail.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.
В списке pgsql-hackers по дате отправления: