> > What I was suggesting with b) was to format up the command line for the > > items prefixed by * in the postmaster, > > do the fork (or fork/exec), and then run the authentication in, say > > PostgresMain. (Note: this is essentially what the fork/exec case currently > > does). > > Yeah, I noticed. If I'd been paying more attention, the already-applied > patch wouldn't have gotten in either, because it already has created > what I consider an unacceptable amount of coupling between PostgresMain > and the sub-postmaster code. If it's still like that when the dust > settles then I will go in and change it myself. PostgresMain has no > business doing *any* of the stuff that is currently #ifdef > EXEC_BACKEND in postgres.c. > [snip] > > > Now, what I think you are suggesting (correct me if I'm wrong), is that we > > should pass along whatever we need to in order to be able to setup the > > fork/exec'd process to run BackendFork more or less unchanged. > > I don't mind making localized changes like passing in the result of > canAcceptConnections, but by and large, yes: I want to run BackendFork > pretty much as-is.
Check out the last patch I sent. It implements your ideas for BackendFork'ing in the fork/exec case, and pretty much lets us revert the previous changes to postgres.c and BackendFork (which I agree is a good thing). 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> ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]