Re: straightening out backend process startup - Mailing list pgsql-hackers

From Andres Freund
Subject Re: straightening out backend process startup
Date
Msg-id 20210805195015.uk7el4hgahmnq277@alap3.anarazel.de
Whole thread Raw
In response to Re: straightening out backend process startup  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: straightening out backend process startup
List pgsql-hackers
Hi,

On 2021-08-03 16:50:24 +0900, Kyotaro Horiguchi wrote:
> At Mon, 2 Aug 2021 09:41:24 -0700, Andres Freund <andres@anarazel.de> wrote in
> > - PostgresMainSingle() should probably not be in postgres.c. We could put it
> >   into postinit.c or ..?
>
> PostgresMainSingle() looks like the single-process version of
> PostgresMain so it is natural that they are placed together in
> postgres.c.  If PostgresMainSingle is constructed as initializing
> standalone first then calling PostgresMain, it might be right that
> PostgresMain calls the initialization function resides in postinit.c
> if !IsUnderPostmaster.
>
> PostgresMain()
> {
>   if (!IsUnderPostmaster)
>       InitSinglePostgres(argv[0]);
>   ...

I find passing argc/argv to functions that don't actually need them, like
PostgresMain during normal operation, confusing. Especially when the argc/argv
values are just manufactured stuff like in the case of PostgresMain(). So I
think it's better to have have the order work the other way round.


> > - My first attempt at PostgresMainSingle() separated the single/multi user
> >   cases a bit more than the code right now, by having a PostgresMainCommon()
> >   which was called by PostgresMainSingle(), PostgresMain(). *Common only
> >   started with the MessageContext allocation, which did have the advantage of
> >   splitting out a few of the remaining conditional actions in PostgresMain()
> >   (PostmasterContext, welcome banner, Log_disconnections). But lead to a bit
> >   more duplication. I don't really have an opinion on what's better.
>
> I'm not sure how it looked like, but isn't it reasonable that quickdie
> and log_disconnections(). handle IsUnderPostmaster instead?  Or for
> log_disconnections, Log_disconnections should be turned off at
> standalone-initialization?

I was wondering about log_disconnections too. The conditional addition of the
callback is all that forces log_disconnections to be PGC_SU_BACKEND rather
than PGC_SUSET too. So I agree that moving a check for Log_disconnections and
IsUnderPostmaster into log_disconnections is a good idea.

I don't understand your reference to quickdie() though?


> > - I had to move the PgStartTime computation to a bit earlier for single user
> >   mode. That seems to make sense to me anyway, given that postmaster does so
> >   fairly early too.
> >
> >   Any reason that'd be a bad idea?
> >
> >   Arguably it should even be a tad earlier to be symmetric.
>
> Why don't you move the code for multiuser as earlier as standalone does?

I think it's the other way round - right now the standalone case is much later
than the multiuser case. Postmaster determines PgStartTime after creating
shared memory, just before starting checkpointer / startup process - whereas
single user mode in HEAD does it just before accepting input for the first
time.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: very long record lines in expanded psql output
Next
From: Bruce Momjian
Date:
Subject: Re: Accidentally dropped constraints: bug?