Re: straightening out backend process startup

From: Andres Freund <andres(at)anarazel(dot)de>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: straightening out backend process startup
Date: 2021-08-05 19:50:15
Message-ID: 20210805195015.uk7el4hgahmnq277@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-08-05 20:09:01 Re: Accidentally dropped constraints: bug?
Previous Message Daniel Verite 2021-08-05 19:40:01 Re: very long record lines in expanded psql output