Re: when the startup process doesn't (logging startup delays)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: when the startup process doesn't (logging startup delays)
Дата
Msg-id CA+TgmoYqesbXKh64YynScwg_7A60B1LrQ_9CMM+7jb1WB611vA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: when the startup process doesn't (logging startup delays)  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Ответы Re: when the startup process doesn't (logging startup delays)  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Nikolay Samokhvalov
Дата:
Сообщение: Re: Amcheck verification of GiST and GIN
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Weird failure with latches in curculio on v15