I said:
> We should either find a way to make the fork/exec path more like the
> existing code, or bite the bullet and change them both.
It occurs to me that you probably need some concrete suggestions about
what to do. Here's one.
There are really three separate sections in this code: the postmaster
(which no longer does much except fork off a subprocess on receipt of a
new connection), the "sub-postmaster" which does client authentication,
and the backend.
Historical note: formerly the sub-postmaster actions were done in the
parent postmaster process, with a sort of poor man's threading logic
to allow the postmaster to interleave multiple client authentication
operations. We had to change that because various libraries like SSL,
PAM, and Kerberos weren't amenable to pseudo-threading.
It is worth maintaining a clean distinction between sub-postmaster and
backend because when we launch a standalone backend, we don't want the
sub-postmaster part of the code. The command line syntax accepted by
PostgresMain() is largely designed for the convenience of the standalone
backend case, with a couple of simple hacks for the under-postmaster case.
Now it seems to me that a lot of the mess in your latest patch comes
from trying to set up the backend command string before you've forked,
and therefore before you've done any of the sub-postmaster actions.
That's not gonna work.
What I'd suggest is adding a new entry point from main.c, say
SubPostmasterMain(), with its own command line syntax. Perhaps
postmaster -fork ... additional args ...
(where -fork is what cues main.c where to dispatch to, and the
additional args are just those that need to be passed from the
postmaster to the sub-postmaster, without any of the additional
information that will be learned by the sub-postmaster during
client authentication.)
In the Windows case the postmaster would fork/exec to this routine,
which would re-load as much of the postmaster context as was needed
and then call BackendFork (which we really oughta rename to something
else). BackendFork would execute the client auth process and then
simply call PostgresMain with a correctly constructed argument list.
In the Unix case we don't bother compiling SubPostmasterMain, we just
fork and go straight to BackendFork as the code does now.
In essence, this design makes SubPostmasterMain responsible for
emulating Unix-style fork(), ie, fork without loss of static variable
contents. It would need to reload as many variables as we needed.
I think this is a cleaner approach since it creates a layer of code
which is simply there in one case and not there in the other, rather
than making arbitrary changes in the layers above and below depending
on #ifdefs.
regards, tom lane
