| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Cc: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Is Recovery actually paused? |
| Date: | 2021-01-16 22:21:42 |
| Message-ID: | CAD21AoByNjTUm98U535xHNuFgwyy+ZJD-wVV11dukJUN227oMA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jan 16, 2021 at 12:28 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> ---
> + /* test for recovery pause if user has requested the pause */
> + if (((volatile XLogCtlData *) XLogCtl)->recoveryPause)
> + recoveryPausesHere(false);
> +
> + now = GetCurrentTimestamp();
> +
>
> Hmm, if the recovery pauses here, the wal receiver isn't launched even
> when wal_retrieve_retry_interval has passed, which seems not good. I
> think we want the recovery to be paused but want the wal receiver to
> continue receiving WAL.
I had misunderstood the code and the patch, please ignore this
comment. Pausing the recovery here is fine with me.
Regards,
--
Masahiko Sawada
EnterpriseDB: https://www.enterprisedb.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2021-01-16 23:04:16 | Re: New Table Access Methods for Multi and Single Inserts |
| Previous Message | Tomas Vondra | 2021-01-16 22:18:19 | Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits |