Re: when the startup process doesn't (logging startup delays) - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: when the startup process doesn't (logging startup delays)
Date
Msg-id CANbhV-Gn8e9ga0PLTopaJ=GcB-A4gTD=Nii8C2jA_Guwn7uOCQ@mail.gmail.com
Whole thread Raw
In response to Re: when the startup process doesn't (logging startup delays)  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: when the startup process doesn't (logging startup delays)
List pgsql-hackers
On Wed, 16 Nov 2022 at 06:47, Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Tue, Nov 15, 2022 at 10:55 PM Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Tue, Nov 15, 2022 at 8:33 AM Bharath Rupireddy
> > <bharath.rupireddyforpostgres@gmail.com> wrote:
> > > Please review the v2 patch.
> >
> > It seems to me that this will call disable_startup_progress_timeout
> > once per WAL record, which seems like an unnecessary expense. How
> > about leaving the code inside the loop just as we have it, and putting
> > if (StandbyMode) disable_startup_progress_timeout() before entering
> > the loop?
>
> That can be done, only if we can disable the timeout in another place
> when the StandbyMode is set to true in ReadRecord(), that is, after
> the standby server finishes crash recovery and enters standby mode.
>
> I'm attaching the v3 patch for further review. Please find the CF
> entry here - https://commitfest.postgresql.org/41/4012/.

begin_startup_progress_phase() checks to see if feature is disabled
twice, so I think you can skip the check and just rely on the check in
enable().

Otherwise, all good.

-- 
Simon Riggs                http://www.EnterpriseDB.com/



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Support logical replication of DDLs
Next
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Data is copied twice when specifying both child and parent table in publication