On Fri, Jan 22, 2021 at 2:18 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Jan 18, 2021 at 9:42 PM Yugo NAGATA <nagata@sraoss.co.jp> wrote:
> > If it is acceptable that pg_is_wal_replay_paused() makes users wait,
> > I'm ok for the current interface. I don't feel the need of
> > pg_is_wal_replay_paluse_requeseted().
>
> Another idea could be that pg_is_wal_replay_paused() could be changed
> to text, and the string could be either 'paused' or 'pause requested'
> or 'not paused'. That way we'd be returning a direct representation of
> the state we're keeping in memory. Some of the complexity in this
> discussion seems to come from trying to squeeze 3 possibilities into a
> Boolean.
>
> Let's also consider that we don't really know whether the client wants
> us to wait or not, and different clients may want different things, or
> maybe not, but we don't really know at this point. If we provide an
> interface that waits, and the client doesn't want to wait but just
> know the current state, they don't necessarily have any great options.
> If we provide an interface that doesn't wait, and the client wants to
> wait, it can poll until it gets the answer it wants. Polling can be
> inefficient, but anybody who is writing a tool that uses this should
> be able to manage an algorithm with some reasonable back-off behavior
> (e.g. try after 10ms, 20ms, keep doubling, max of 5s, or something of
> that sort), so I'm not sure there's actually any real problem in
> practice. So to me it seems more likely that an interface that is
> based on waiting will cause difficulty for tool-writers than one that
> does not.
>
> Other people may feel differently, of course...
I think this is the better way of handling this. So +1 from my side,
I will send an updated patch.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
