From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Thom Brown <thom(at)linux(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: Silent failure with invalid hba_file setting |
Date: | 2011-10-19 05:22:08 |
Message-ID: | CABUevEyzNXzOU3TQnC6o4cZc9XCOySvu1BgRc3rEE1DgxYVbWA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Oct 19, 2011 6:21 AM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On tis, 2011-10-18 at 18:38 -0400, Tom Lane wrote:
> >> Well, an actually empty pg_hba.conf file would have the same problem,
> >> and it's pretty hard to see any situation where it would be useful to
> >> start the postmaster and not let it accept any connections. Should we
> >> add a check to consider it an error if the file doesn't contain at
least
> >> one HBA record?
>
> > If you try to connect and it doesn't find a record, it will tell you.
>
> Yeah, but the damage is already done. I see the main practical benefit
> of this being to prevent accidental loading of a trashed pg_hba file.
Yeah, definitely. It's very much a pita when you accidentally do that with a
syntax error on <8.4, %. So while I haven't actually managed to hit his
specific problem myself, +1 for this approach.
> > I wouldn't add extra special checks for that. It might not be
> > completely unreasonable to have a standby that no one can connect to,
> > for example.
>
> Well, you couldn't monitor its state then, so I don't find that example
> very convincing. But if you were intent on having that, you could
> easily set up a pg_hba file containing only "reject" entries.
>
Yeah, seems reasonable to put a (very) small amount of extra work in the
path of a very uncommon scenario in order to protect users in the common
one...
/Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-10-19 06:31:10 | Re: loss of transactions in streaming replication |
Previous Message | Tom Lane | 2011-10-19 05:10:02 | Re: (patch) regression diffs on collate.linux.utf8 test |