On Wed, Oct 28, 2020 at 7:51 PM David G. Johnston <david.g.johns...@gmail.com> wrote: > >> And also in case if the given pid is not a >> backend pid, we are throwing a warning and returning false but not >> error. >> >> Similarly we can return false on timeout, if required a >> warning. Thoughts? > > IMO, if there are multiple ways to return false then all of them should emit > a notice or warning describing which of the false conditions was hit. >
Currently there are two possibilities in pg_teriminate_backend where a warning is thrown and false is returned. 1. when the process with a given pid is not a backend 2. when we can not send the SIGTERM to the given backend. I will add another case to throw the warning and return false when timeout occurs. >> >> > >> IIUC, do we need a new option, something like pg_wait_backend(pid, >> > >> timeout, waituntil) where "waituntil" if specified "idle" waits until >> > >> the given backend goes to idle mode, or "termination" waits until >> > >> termination? >> > >> > Isn't this wait-for-idle mode fragile? Because there is no guarantee >> > that the backend is still in idle state when pg_wait_backend(idle) returns. >> > 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? > >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? > >For consideration. I'll give a point for being consistent with other existing >functions, and it wouldn't be hard to extend should we want to add the option >later, so while the more flexible API seems better on its face limiting >ourselves to >boolean false isn't a big deal to me; especially as I've yet to >write code that would make use of this feature. > I see that this pg_wait_backend(pid, timeout) functionality can be right away used in two places, one in dblink.sql where wait_pid is being used, second in postgres_fdw.sql where terminate_backend_and_wait() is being used. However we can make these changes as part of another patch set after the proposed two new functions are finalized and reviewed. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
