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

From Robert Haas
Subject Re: when the startup process doesn't (logging startup delays)
Date
Msg-id CA+TgmoYqesbXKh64YynScwg_7A60B1LrQ_9CMM+7jb1WB611vA@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)  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
On Tue, Nov 22, 2022 at 6:05 AM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
> If we place just the Assert(!StandbyMode); in
> enable_startup_progress_timeout(), it fails for
> begin_startup_progress_phase() in ResetUnloggedRelations() because the
> InitWalRecovery(), that sets StandbyMode to true, is called before
> ResetUnloggedRelations() . However, with the if (StandbyMode) {
> return; }, we fail to report progress of ResetUnloggedRelations() in a
> standby, which isn't a good idea at all because we only want to
> disable the timeout during the recovery's main loop.

Ugh. Well, in that case, I guess my vote is to forget about this whole
Assert business and just commit what you had in v4. Does that work for
you?

Protecting against specifically the situation where we're in the
standby's main redo apply loop is not really what I had in mind here,
but this is already sort of weirdly complicated-looking, and making it
more weirdly complicated-looking to achieve the kind of protection
that I had in mind doesn't really seem worth it.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Nikolay Samokhvalov
Date:
Subject: Re: Amcheck verification of GiST and GIN
Next
From: Robert Haas
Date:
Subject: Re: Weird failure with latches in curculio on v15