| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | dilipbalaut(at)gmail(dot)com |
| Cc: | nagata(at)sraoss(dot)co(dot)jp, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, sawada(dot)mshk(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, robertmhaas(at)gmail(dot)com, simon(at)2ndquadrant(dot)com |
| Subject: | Re: Is Recovery actually paused? |
| Date: | 2021-02-09 06:05:43 |
| Message-ID: | 20210209.150543.1025683953813424605.horikyota.ntt@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Sorry, I made a mistake here.
At Tue, 09 Feb 2021 14:55:23 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> At Tue, 9 Feb 2021 09:47:58 +0530, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote in
> > APIs the wait logic can be implemented in the application code which
> > is actually using these APIs and IMHO that will give better control to
> > the users.
>
> Year, with the PoC pg_wal_replay_pause() can make a short wait as a
> side-effect but the tri-state patch also can add a function to wait
> for the state suffices.
I said that it is surprising that pg_is_wal_replay_paused() waits for
the state change. But I didn't say that pg_wal_replay_pause()
shouldn't wait for the actual pause.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ajin Cherian | 2021-02-09 06:27:29 | Re: repeated decoding of prepared transactions |
| Previous Message | Kyotaro Horiguchi | 2021-02-09 06:00:34 | Re: Is Recovery actually paused? |