Re: Is Recovery actually paused? - Mailing list pgsql-hackers
From | Kyotaro Horiguchi |
---|---|
Subject | Re: Is Recovery actually paused? |
Date | |
Msg-id | 20210119.140010.1037648043487816682.horikyota.ntt@gmail.com Whole thread Raw |
In response to | Re: Is Recovery actually paused? (Yugo NAGATA <nagata@sraoss.co.jp>) |
Responses |
Re: Is Recovery actually paused?
|
List | pgsql-hackers |
At Tue, 19 Jan 2021 11:41:18 +0900, Yugo NAGATA <nagata@sraoss.co.jp> wrote in > On Sun, 17 Jan 2021 11:33:52 +0530 > Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > > > > > > > I think the current pg_is_wal_replay_paused() already has another purpose; > > > > > > this waits recovery to actually get paused. If we want to limit this API's > > > > > > purpose only to return the pause state, it seems better to fix this to return > > > > > > the actual state at the cost of lacking the backward compatibility. If we want > > > > > > to know whether pause is requested, we may add a new API like > > > > > > pg_is_wal_replay_paluse_requeseted(). Also, if we want to wait recovery to actually > > > > > > get paused, we may add an option to pg_wal_replay_pause() for this purpose. > > > > > > > > > > > > However, this might be a bikeshedding. If anyone don't care that > > > > > > pg_is_wal_replay_paused() can make user wait for a long time, I don't care either. > > > > > > > > > > I don't think that it will be blocked ever, because > > > > > pg_wal_replay_pause is sending the WakeupRecovery() which means the > > > > > recovery process will not be stuck on waiting for the WAL. > > > > > > Yes, there is no stuck on waiting for the WAL. However, it can be stuck during resolving > > > a recovery conflict. The process could wait for max_standby_streaming_delay or > > > max_standby_archive_delay at most before recovery get completely paused. > > > > Okay, I agree that it is possible so for handling this we have a > > couple of options > > 1. pg_is_wal_replay_paused(), interface will wait for recovery to > > actually get paused, but user have an option to cancel that. So I > > agree that there is currently no option to just know that recovery > > pause is requested without waiting for its actually get paused if it > > is requested. So one option is we can provide an another interface as > > you mentioned pg_is_wal_replay_paluse_requeseted(), which can just > > return the request status. I am not sure how useful it is. > > 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(). FWIW, the name "pg_is_wal_replay_paused" is suggesting "to know whether recovery is paused or not at present" and it would be surprising to see it to wait for the recovery actually paused by default. I think there's no functions to wait for some situation at least for now. If we wanted to wait for some condition to make, we would loop over check-and-wait using plpgsql. If you desire to wait to replication to pause by a function, I would do that by adding a parameter to the function. pg_is_wal_replay_paused(OPTIONAL bool wait_for_pause) regards. -- Kyotaro Horiguchi NTT Open Source Software Center
pgsql-hackers by date: