
Tom Lane wrote:
> What does SSDataBaseInit have to do with acquiring configuration
> parameters?  (Answer: nothing.)  Why is it being called here at all,
> and why only in the EXEC_BACKEND case?  Sure can't figure 
> that out from
> the uncommented code.  Is it a good idea to do it?  I rather doubt it
> --- that routine does on_exit_reset, which would lose any previously
> registered exit callbacks, which is something that should only happen
> immediately after fork(), not as far down in BootstrapMain as this is
> being done.

That is a remaining wart. Having fixed a similar pattern in the backend
creation, I asked whether or not fixing the Bootstrap process creation was
overkill, and took no answer to be in the affirmative...


> But Andrew's complaint already had some merit even before this work
> started.  We probably ought to rear back and contemplate the overall
> structure of postmaster.c and postgres.c, and see what we can 
> do to make it more comprehensible.  I don't have any immediate thoughts 
> about what to do, just a bee in my bonnet that it needs to be done.  Any
ideas?

If you like, I'll quickly provide a reversion of the BackendRun/Init split,
and perhaps implement a "SubBootstrapMain"-ism... but this doesn't really
help things overall. Is it at least a better point to start from?

Cheers,
Claudio

--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Mon, 2 Feb 2004 11:11:16 +1100 
Claudio Natoli <claudio.natoli@memetrics.com>
Re: fork/exec 
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> If you like, I'll quickly provide a reversion of the BackendRun/Init split,
> and perhaps implement a "SubBootstrapMain"-ism... but this doesn't really
> help things overall. Is it at least a better point to start from?

I'd say think first and code later.  Do we want to reunify those
routines, or is there some purpose in having a split?  Can't see
what offhand, but the whole problem is this code has gotten away
from us complexity-wise.  We should first think about what the
structure ought to be.

One thought I had was that there should be a common subroutine to do the
stuff that a new postmaster subprocess needs to do immediately at
startup.  This includes setting IsUnderPostmaster, MyProcPid,
on_exit_reset in the fork() case, reloading global variables in the
exec() case, and maybe a couple other things I've forgotten.  We've
allowed that code to get duplicated across several places now.  I had
been thinking that this was solely an issue for the exec case (and thus
that hiding it in a SubPostmasterMain layer would solve the problem),
but really there are several critical things that have to happen there
in the fork case as well.  We could have a PostmasterChildSetup routine
that is called in both cases, and behaves slightly differently in each
case, but once it returns the overall state of the new subprocess is the
same in both cases.

			regards, tom lane

Sun, 01 Feb 2004 19:44:32 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: fork/exec 