| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: hba load error and silent mode |
| Date: | 2009-08-24 15:29:25 |
| Message-ID: | 12193.1251127765@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2009-08-24 15:42:14 | Re: DELETE syntax on JOINS |
| Previous Message | Andrew Dunstan | 2009-08-24 15:15:24 | Re: hba load error and silent mode |