From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | dilipbalaut(at)gmail(dot)com, simon(at)2ndquadrant(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Is Recovery actually paused? |
Date: | 2020-10-22 01:28:57 |
Message-ID: | 20201022.102857.1066340087233407314.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 21 Oct 2020 11:14:24 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in
> On Wed, Oct 21, 2020 at 7:16 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > 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.
..
> 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.
The paused state is shown in pg_stat_activity.wait_event and it is
strange that pg_is_wal_replay_paused() is inconsistent with the
column. To make them consistent, we need to call recoveryPausesHere()
at the end of WaitForWALToBecomeAvailable() and let
pg_wal_replay_pause() call WakeupRecovery().
I think we don't need a separate function to find the state.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | tsunakawa.takay@fujitsu.com | 2020-10-22 01:33:31 | RE: [Patch] Optimize dropping of relation buffers using dlist |
Previous Message | Michael Paquier | 2020-10-22 01:25:19 | Re: [patch] Fix checksum verification in base backups for zero page headers |