> > 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
> > 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.  
> > Now, what I think you are suggesting (correct me if I'm  wrong), is that
> > 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


Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to