Re: Should rename "startup process" to something else? - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Should rename "startup process" to something else?
Date
Msg-id CALj2ACULYsfL5GSk83RQxFEP_cWLzU0LMUQp05_KpcKn4kn=dQ@mail.gmail.com
Whole thread Raw
In response to Should rename "startup process" to something else?  (Rushabh Lathia <rushabh.lathia@gmail.com>)
Responses Re: Should rename "startup process" to something else?
List pgsql-hackers
On Mon, Nov 15, 2021 at 8:03 PM Rushabh Lathia <rushabh.lathia@gmail.com> wrote:
> Robert and I wondered whether we would like to rename the startup
>
> process.  The reason for doing this is that the current name doesn't
>
> make any sense, as in the stand-by mode replay loop as the main
>
> loop, the startup process stays around.

The startup process main function looks to be to do some
initialization required for recovery and do the recovery, exit if it
is a crash recovery or stay there if it is a standby recovery. Apart
from these I'm not sure it does any non-recovery tasks. Does the
startup process have any relevance or work to do if the server state
is DB_SHUTDOWNED i.e the server was shutdown properly? I think yes,
although it doesn't enter the recovery/REDO loop, it does a bunch of
other things like updating the control file, pre-allocating WAL files,
updating shared memory state to allow other backends to write WAL and
so on. By keeping this in mind, just renaming the startup process to
"recovery" or some other doesn't look good IMO. Instead, we can live
with it and be happy with the ps display update that we do in
XLogFileRead.

> I think a better name for the process may be “recovery” or “WAL_replay”
>
> or maybe someone has a better idea.  One can say that startup is a very
>
> generic name, so in the future, it gives flexibility in terms of assigning
>
> any sort of 'work’.  But in standby mode, the name “startup” doesn’t
>
> make sense.
>
> Open for suggestions and thoughts.

If at all, we were to change the startup process to "recovery" or some
other, it's not going to be a tiny change, we need to change the code
with some user facing error message, docs, testsm which isn't good
from code maintainability and especially the diff it creates with the
back branches that we support.

Others may have better thoughts.

Regards,
Bharath Rupireddy.



pgsql-hackers by date:

Previous
From: Xiaozhe Yao
Date:
Subject: Re: Propose a new hook for mutating the query bounds
Next
From: Greg Nancarrow
Date:
Subject: Re: row filtering for logical replication