From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Is Recovery actually paused? |
Date: | 2021-01-23 08:06:12 |
Message-ID: | CAFiTN-t3DfrUEiL_pPyov9NoXVpANqVJ+Gei89HZJmSMnCNAfw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 23, 2021 at 9:56 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Fri, Jan 22, 2021 at 2:18 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Mon, Jan 18, 2021 at 9:42 PM Yugo NAGATA <nagata(at)sraoss(dot)co(dot)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.
Please find the patch for the same. I haven't added a test case for
this yet. I mean we can write a test case to pause the recovery and
get the status. But I am not sure that we can really write a reliable
test case for 'pause requested' and 'paused'.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
v6-0001-pg_is_wal_replay_paused-will-return-the-status-of.patch | application/octet-stream | 12.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2021-01-23 08:14:44 | Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION |
Previous Message | Amit Langote | 2021-01-23 07:10:24 | Re: simplifying foreign key/RI checks |