Skip site navigation (1) Skip section navigation (2)

Re: Why don't we allow DNS names in pg_hba.conf?

From: Jon Jensen <jon(at)endpoint(dot)com>
To: Tino Wildenhain <tino(at)wildenhain(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Andrew Dunstan <andrew(at)dunslane(dot)net>,Euler Taveira de Oliveira <eulerto(at)yahoo(dot)com(dot)br>,"Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>,Andreas Pflug <pgadmin(at)pse-consulting(dot)de>,"Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why don't we allow DNS names in pg_hba.conf?
Date: 2006-01-03 20:00:24
Message-ID: Pine.LNX.4.64.0601031247100.20979@ybpnyubfg.ybpnyqbznva (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 3 Jan 2006, Tino Wildenhain wrote:

>>> One thing that bothers me slightly is that we would need to look up each
>>> name (at least until we found a match) for each connection. If you had
>>> lots of names in your pg_hba.conf that could be quite a hit.
>>
>> A possible answer to that is to *not* look up the names from
>> pg_hba.conf, but instead restrict the feature to matching the
>> reverse-DNS name of the client.  This limits the cost to one lookup per
>> connection instead of N (and it'd be essentially free if you have
>> log_hostnames turned on, since we already do that lookup in that case).
>
> Or alternatively (documented) scan and translate the names
> only on restart or sighup. This would limit the overhead
> and changes to the confile-scanner only and would
> at least enable symbolic names in the config files.
> (Of course w/o any wildcards - that would be the drawback)

That's what I suggested yesterday, but others didn't like it and the 
possibility of using /etc/hosts or a name server on the local network to 
mitigate speed concerns makes me think they're right.

Jon

-- 
Jon Jensen
End Point Corporation
http://www.endpoint.com/

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-01-03 20:51:11
Subject: Re: cvs tip - stats buffer process consuming 100% cpu
Previous:From: Bruce MomjianDate: 2006-01-03 19:53:23
Subject: Re: cvs tip - stats buffer process consuming 100% cpu

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group