Re: Silent failure with invalid hba_file setting

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Silent failure with invalid hba_file setting
Дата
Msg-id CABUevEyzNXzOU3TQnC6o4cZc9XCOySvu1BgRc3rEE1DgxYVbWA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Silent failure with invalid hba_file setting  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
<p><br /> On Oct 19, 2011 6:21 AM, "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>
wrote:<br/> ><br /> > Peter Eisentraut <<a href="mailto:peter_e@gmx.net">peter_e@gmx.net</a>> writes:<br />
>> On tis, 2011-10-18 at 18:38 -0400, Tom Lane wrote:<br /> > >> Well, an actually empty pg_hba.conf
filewould have the same problem,<br /> > >> and it's pretty hard to see any situation where it would be useful
to<br/> > >> start the postmaster and not let it accept any connections.  Should we<br /> > >> add a
checkto consider it an error if the file doesn't contain at least<br /> > >> one HBA record?<br /> ><br />
>> If you try to connect and it doesn't find a record, it will tell you.<br /> ><br /> > Yeah, but the
damageis already done.  I see the main practical benefit<br /> > of this being to prevent accidental loading of a
trashedpg_hba file.<p>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. <br /><p>>
>I wouldn't add extra special checks for that.  It might not be<br /> > > completely unreasonable to have a
standbythat no one can connect to,<br /> > > for example.<br /> ><br /> > Well, you couldn't monitor its
statethen, so I don't find that example<br /> > very convincing.  But if you were intent on having that, you
could<br/> > easily set up a pg_hba file containing only "reject" entries.<br /> ><p>Yeah, seems reasonable to
puta (very) small amount of extra work in the path of a very uncommon scenario in order to protect users in the common
one...<p>/Magnus <br /> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: (patch) regression diffs on collate.linux.utf8 test
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: loss of transactions in streaming replication