On Wed, Oct 28, 2020 at 6:50 AM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote:
> Thanks for the comments. > > On Wed, Oct 28, 2020 at 6:41 PM Fujii Masao <masao.fu...@oss.nttdata.com> > wrote: > > > > I prefer that false is returned when the timeout happens, > > like pg_promote() does. > > > > Earlier it was suggested to error out on timeout. 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. Since users can not > guess on time it takes to terminate or become idle, throwing error > seems to be odd on timeout. I don't see how the one follows from the other. 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. > > > > >> 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. 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. David J.
