> > 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>
