Re: Is Recovery actually paused?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Is Recovery actually paused?
Дата
Msg-id CA+Tgmoao0e4LbGaaruNz-DZHTFG5ocvZ2F0zSVjheVQU=rRnsw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Is Recovery actually paused?  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Is Recovery actually paused?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
On Wed, Oct 21, 2020 at 7:16 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> I have noticed one more issue, the problem is that if the recovery
> process is currently not processing any WAL and just waiting for the
> WAL to become available then the pg_is_wal_replay_paused will be stuck
> forever.  Having said that there is the same problem even if we design
> the new interface which checks whether the recovery is actually paused
> or not because until the recovery process gets the next wal it will
> not check whether the recovery pause is requested or not so the actual
> recovery paused flag will never be set.
>
> One idea could be, if the recovery process is waiting for WAL and a
> recovery pause is requested then we can assume that the recovery is
> paused because before processing the next wal it will always check
> whether the recovery pause is requested or not.

That seems fine, because the user's question is presumably whether the
pause has taken effect so that no more records will be replayed
barring an un-paused.

However, it might be better to implement this by having the system
absorb the pause immediately when it's in this state, rather than
trying to detect this state and treat it specially.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: [patch] [doc] Introduce view updating options more succinctly
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Custom compression methods