Re: fork/exec - Mailing list pgsql-hackers

From Tom Lane
Subject Re: fork/exec
Date
Msg-id 17270.1075682672@sss.pgh.pa.us
Whole thread Raw
In response to Re: fork/exec  (Claudio Natoli <claudio.natoli@memetrics.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "Nicolai Tufar"
Date:
Subject: Q: How ORDER BY is being done inetrnally?
Next
From: Claudio Natoli
Date:
Subject: Re: fork/exec