Re: Is Recovery actually paused?
От | Simon Riggs |
---|---|
Тема | Re: Is Recovery actually paused? |
Дата | |
Msg-id | CANP8+jLsALWd0w=4t3yU7pfaf04SW_xGyOvXtfkA5i3kPMjKuA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Is Recovery actually paused? (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Is Recovery actually paused?
|
Список | pgsql-hackers |
On Tue, 20 Oct 2020 at 09:50, Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > Why would we want this? What problem are you trying to solve? > > > > The requirement is to know the last replayed WAL on the standby so > > unless we can guarantee that the recovery is actually paused we can > > never get the safe last_replay_lsn value. > > > > > If we do care, why not fix pg_is_wal_replay_paused() so it responds as you wish? > > > > Maybe we can also do that but pg_is_wal_replay_paused is an existing > > API and the behavior is to know whether the recovery paused is > > requested or not, So I am not sure is it a good idea to change the > > behavior of the existing API? > > > > Attached is the POC patch to show what I have in mind. If you don't like it, I doubt anyone else cares for the exact current behavior either. Thanks for pointing those issues out. It would make sense to alter pg_wal_replay_pause() so that it blocks until paused. I suggest you add the 3-value state as you suggest, but make pg_is_wal_replay_paused() respond: if paused, true if requested, wait until paused, then return true else false That then solves your issues with a smoother interface. -- Simon Riggs http://www.EnterpriseDB.com/
В списке pgsql-hackers по дате отправления: