Re: hba load error and silent mode - Mailing list pgsql-hackers

From Tom Lane
Subject Re: hba load error and silent mode
Date
Msg-id 12193.1251127765@sss.pgh.pa.us
Whole thread Raw
In response to Re: hba load error and silent mode  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> It might be that a reasonable solution on our end would be for
>> pmdaemonize to point stdout/stderr someplace other than /dev/null,
>> perhaps "$PGDATA/postmaster.log"?  Of course, it's not clear what
>> we're supposed to do if that open() fails ...

> Well, yes, but that is at least a comparatively low risk, certainly much 
> much lower than the risk having a faulty hba file, for example.

> This sounds like a reasonable approach.

Actually, if people are happy with that basic behavior, I think we could
make it robust: open /dev/null and $PGDATA/postmaster.log *before* we
fork away from the terminal session.  On failure, report that and exit(1).
On success, go ahead and fork.  Failure of the subsequent dup2() calls
should be just about impossible --- in fact, so far as I can tell from
the SUS documents, if we put in a loop for EINTR then there is no
documented way for them to fail.

If no objections, I'll be happy to make this happen.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: hba load error and silent mode
Next
From: Alvaro Herrera
Date:
Subject: Re: DELETE syntax on JOINS