| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Disable startup progress timeout during standby WAL replay |
| Date: | 2026-06-11 04:39:22 |
| Message-ID: | CAHGQGwGUkaKRqpjqDKy5VUr65zm47+E3f5SYiHAP320Gb+QDWg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 11, 2026 at 11:58 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
> I wonder whether we need to disable the startup progress timeout in
> EnableStandbyMode() in the first place, if the intention is only to
> suppress progress reporting during WAL replay on a standby.
There can be cases where WAL replay starts with StandbyMode == false
and EnableStandbyMode() is called later during WAL replay. For example,
*as far as I remember correctly*, that might happen when starting with
standby.signal but without backup_label. In such cases, we would still want
EnableStandbyMode() to disable the timeout.
> Wouldn't it be simpler to handle the standby case at the existing
> check, like this?
>
> if (!StandbyMode)
> begin_startup_progress_phase();
> + else
> + disable_startup_progress_timeout();
I thought the same at first, too. But I just thought the timeout should not
be enabled even while reading the first WAL record, so I placed
the check before reading the first record.
Regards,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Dilip Kumar | 2026-06-11 04:12:32 | Re: Proposal: Conflict log history table for Logical Replication |