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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: when the startup process doesn't (logging startup delays)
Date: 2021-10-26 14:06:40
Message-ID: CA+TgmoZ0b7JkNexaoGDXJ=8Zq+_NFZBek1oyyPU+DDsRi1dsCw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 26, 2021 at 4:19 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-10-26 14:25:32 Re: Suggestion: Unified options API. Need help from core team
Previous Message Markus Wanner 2021-10-26 14:02:22 Re: pgsql: Remove unused wait events.