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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings