Magnus Hagander writes:
> On Mon, Aug 24, 2009 at 20:51, Andrew Dunstan wrote:
>> We didn't check HBA validity at startup time before, did we? I would not be
>> surprised to get more complaints now.
Good point.
> We checked some of it, but we check it a whole lot more now.
> +1 for backpatching
On Mon, Aug 24, 2009 at 20:51, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>
>>>
>>> Tom Lane wrote:
>>>
Oh, you mean move load_hba *down*, past the syslogger startup?
Yeah, that would probably be all right.
>>
>>
>>>
>>> Well, that's what I origin
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Oh, you mean move load_hba *down*, past the syslogger startup?
Yeah, that would probably be all right.
Well, that's what I originally said, yes ;-)
But I don't think that precludes your more general suggest
Andrew Dunstan writes:
> Tom Lane wrote:
>> Oh, you mean move load_hba *down*, past the syslogger startup?
>> Yeah, that would probably be all right.
> Well, that's what I originally said, yes ;-)
> But I don't think that precludes your more general suggestion regarding
> startup errors. In par
Tom Lane wrote:
Magnus Hagander writes:
I don't see why we couldn't move the hba call specifically, though.
That's a fairly common error, so it would be good if the output went
to the place that is actually configured in postgresql.conf. It's at
least a lot more likely than most other thin
Magnus Hagander writes:
> I don't see why we couldn't move the hba call specifically, though.
> That's a fairly common error, so it would be good if the output went
> to the place that is actually configured in postgresql.conf. It's at
> least a lot more likely than most other things that are prio
On Mon, Aug 24, 2009 at 16:31, Tom Lane wrote:
> Andrew Dunstan writes:
>> (Maybe there's a good case for deprecating silent mode.
>
> +1. The only reason to use it is that an init-script writer is too
> lazy to deal with things properly --- the thing in question here being
> exactly to think of
Andrew Dunstan 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 ...
>
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
Andrew Dunstan writes:
> (Maybe there's a good case for deprecating silent mode.
+1. The only reason to use it is that an init-script writer is too
lazy to deal with things properly --- the thing in question here being
exactly to think of a place for early failure messages to go.
You can *not*
On Mon, Aug 24, 2009 at 02:57:02PM +0200, Magnus Hagander wrote:
> On Mon, Aug 24, 2009 at 14:39, Andrew Dunstan wrote:
> >
> > Last night I had to deal with a puzzled user of version 8.4 who found
> > postgres refused to start but didn't log any error. It turned out that
> > there was an error i
Magnus Hagander wrote:
(Maybe there's a good case for deprecating silent mode. I'm not sure why
Suse uses it. Other distros don't seem to feel the need.)
Could be, but even with silent_mode=off that would be a problem, no?
as in, the log wouldn't go where you'd expect it to go.
It
On Mon, Aug 24, 2009 at 14:39, Andrew Dunstan wrote:
>
> Last night I had to deal with a puzzled user of version 8.4 who found
> postgres refused to start but didn't log any error. It turned out that
> there was an error in the pg_hba.conf file, and the client was running in
> silent mode (the SU
Last night I had to deal with a puzzled user of version 8.4 who found
postgres refused to start but didn't log any error. It turned out that
there was an error in the pg_hba.conf file, and the client was running
in silent mode (the SUSE default).
This seems like a bug, and it's certainly n
14 matches
Mail list logo
