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

From Bharath Rupireddy
Subject Re: when the startup process doesn't (logging startup delays)
Date
Msg-id CALj2ACXwH5FDv7LCsp59ru9+TTpD_=3CS2F3X-f0e-5Eb8+91Q@mail.gmail.com
Whole thread Raw
In response to Re: when the startup process doesn't (logging startup delays)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: when the startup process doesn't (logging startup delays)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Jul 28, 2021 at 7:02 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Jul 28, 2021 at 5:24 AM Nitin Jadhav
> <nitinjadhavpostgres@gmail.com> wrote:
> > I also agree that this is the better place to do it. Hence modified
> > the patch accordingly. The condition "!AmStartupProcess()" is added to
> > differentiate whether the call is done from a startup process or some
> > other process. Actually StartupXLOG() gets called in 2 places. one in
> > StartupProcessMain() and the other in InitPostgres(). As the logging
> > of the startup progress is required only during the startup process
> > and not in the other cases,
>
> The InitPostgres() case occurs when the server is started in bootstrap
> mode (during initdb) or in single-user mode (postgres --single). I do
> not see any reason why we shouldn't produce progress messages in at
> least the latter case. I suspect that someone who is in the rather
> desperate scenario of having to use single-user mode would really like
> to know how long the server is going to take to start up.

+1 to emit the same log messages in single-user mode and basically
whoever calls StartupXLOG. Do we need to adjust the GUC parameter
log_startup_progress_interval(a reasonable value) so that the logs are
generated by default?

> Perhaps during initdb we don't want messages, but I'm not sure that we
> need to do anything about that here. None of the messages that the
> server normally produces show up when you run initdb, so I guess they
> are getting redirected to /dev/null or something.

I enabled the below log message in XLogFlush and ran initdb, it is
printing these logs onto the stdout, looks like the logs have not been
redirected to /dev/null in initdb/bootstrap mode.

#ifdef WAL_DEBUG
if (XLOG_DEBUG)
elog(LOG, "xlog flush request %X/%X; write %X/%X; flush %X/%X",
LSN_FORMAT_ARGS(record),
LSN_FORMAT_ARGS(LogwrtResult.Write),
LSN_FORMAT_ARGS(LogwrtResult.Flush));
#endif

So, even in bootstrap mode, can we use the above #ifdef WAL_DEBUG and
XLOG_DEBUG to print those logs? It looks like the problem with these
macros is that they are not settable by normal users in the production
environment, but only by the developers. I'm not sure how much it is
helpful to print the startup process progress logs in bootstrap mode.
Maybe we can use the IsBootstrapProcessingMode macro to disable these
logs in the bootstrap mode.

> So I don't think that using AmStartupProcess() for this purpose is right.

Agree.

Regards,
Bharath Rupireddy.



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Have I found an interval arithmetic bug?
Next
From: Alvaro Herrera
Date:
Subject: Re: Minimal logical decoding on standbys