Re: Why don't we allow DNS names in pg_hba.conf?
От | Jon Jensen |
---|---|
Тема | Re: Why don't we allow DNS names in pg_hba.conf? |
Дата | |
Msg-id | Pine.LNX.4.64.0601021144340.20979@ybpnyubfg.ybpnyqbznva обсуждение исходный текст |
Ответ на | Re: Why don't we allow DNS names in pg_hba.conf? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Why don't we allow DNS names in pg_hba.conf?
|
Список | pgsql-hackers |
On Mon, 2 Jan 2006, Tom Lane wrote: >> (1) What Tom proposed is that we store the hostname and do a new DNS >> lookup for every connection. That could be useful in certain situations, >> but I wouldn't use it for a busy production server. The additional time >> for DNS lookups (even with a fast local caching nameserver) would not be a >> price I'd want to pay for the convenience. > > Can you demonstrate that this is actually a serious concern next to the > total time spent launching a backend? I can't measure any real change > in total time for "psql -l" when log_hostname is enabled, which should > be a comparable hit. The difference is negligible when using a UNIX socket (of course) or names listed in /etc/hosts. But it's certainly slower in my tests if you really use DNS. On a run of 1000 connections doing "psql -l", it takes 18.89s without the DNS lookup for log_hostname, and 31.5s with. Or run as a one-off, it's 0.032 to 0.041s. Enough to make a difference on a busy server taking connections only over a local network. However, if I consider the likely use cases, this feature probably isn't important to such highly speed-sensitive servers anyway. And for those who want every last bit of speed possible, /etc/hosts still allows them to use this feature without a noticeable speed penalty. If the documentation mentions that DNS lookups are done for every request if you choose to use hostnames in pg_hba.conf, I think that's fair enough. > I started out proposing a one-line change. The odds of this ever > getting done drop by an order of magnitude every time someone proposes > another order-of-magnitude increase in the work required... It sounds like it's beyond a one-line change anyway, due to the possibility of multiple IP addresses coming back. But I agree that complicating this simple feature is overkill. The database is not a firewall, and doesn't have a firewall's speed due to connection overhead anyway. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ...
В списке pgsql-hackers по дате отправления: