| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Is Recovery actually paused? |
| Date: | 2020-10-20 07:41:18 |
| Message-ID: | CANP8+j+fx0H_Qi4b1fxTVtaVtgNAQgy+xsnW=QB+5Bp__5CjbQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 19 Oct 2020 at 15:11, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> We have an interface to pause the WAL replay (pg_wal_replay_pause) and
> to know whether the WAL replay pause is requested
> (pg_is_wal_replay_paused). But there is no way to know whether the
> recovery is actually paused or not. Actually, the recovery process
> might process an extra WAL before pausing the recovery. So does it
> make sense to provide a new interface to tell whether the recovery is
> actually paused or not?
>
> One solution could be that we convert the XLogCtlData->recoveryPause
> from bool to tri-state variable (0-> recovery not paused 1-> pause
> requested 2-> actually paused).
>
> Any opinion on this?
Why would we want this? What problem are you trying to solve?
If we do care, why not fix pg_is_wal_replay_paused() so it responds as you wish?
--
Simon Riggs http://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2020-10-20 07:52:21 | Re: Is Recovery actually paused? |
| Previous Message | gkokolatos | 2020-10-20 07:30:39 | Re: Commitfest manager 2020-11 |