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+TgmoZ0b7JkNexaoGDXJ=8Zq+_NFZBek1oyyPU+DDsRi1dsCw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: when the startup process doesn't (logging startup delays)  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Список pgsql-hackers
On Tue, Oct 26, 2021 at 4:19 AM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
> Can we also log the total time the startup process took to recover,
> and also the total time each stage of the recovery/redo processing
> took: 1) into a file or 2) emitting that info via a new hook 3) into a
> system catalog table (assuming at the end of the recovery the database
> is in a consistent state, but I'm not sure if we ever update any
> catalog tables in/after the startup/recovery phase).

#3 would be hard to do because there could be any number of databases
and it is unclear which one we ought to update. Also, we'd have to
launch a background worker to connect to that database in order to do
it, and be prepared for what happens if that worker fails to get the
work done for whatever reason. Also, it is unclear why we should only
log this specific thing to a system catalog and not anything else.

#1 and #2 could certainly be done, but I'm not sure what the use case
is, and I think it's a separate proposal from what we did here. So I
think a new thread would be appropriate if you want to make a new
proposal.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Markus Wanner
Дата:
Сообщение: Re: pgsql: Remove unused wait events.
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Suggestion: Unified options API. Need help from core team