Re: hba load error and silent mode

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: Raw Message | Whole Thread | 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

In response to

Browse pgsql-hackers by date

  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