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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-02 18:55:53
Message-ID: Pine.LNX.4.64.0601021144340.20979@ybpnyubfg.ybpnyqbznva (view raw, whole thread or download thread mbox)
Lists: 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 Jensen
End Point Corporation
Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ...

In response to


pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-01-02 18:58:31
Subject: Re: EINTR error in SunOS
Previous:From: Stefan KaltenbrunnerDate: 2006-01-02 18:54:59
Subject: Re: What bison versions are installed on buildfarm machines?

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