Re: postmaster / resolv.conf / dns problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Cott Lang <cott(at)internetstaff(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: postmaster / resolv.conf / dns problem
Date: 2005-12-02 14:48:04
Message-ID: 2513.1133534884@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Cott Lang <cott(at)internetstaff(dot)com> writes:
>> What exactly does
>> "would not accept" mean --- what was the exact error message,
>> and was there anything in the postmaster log?

> There was nothing in the postmaster log indicating a problem.

> The only thing I saw strange was multiple postmasters spawning and
> disappearing.

> The errors I got in the JDBC drivers was the connection pool timing out
> trying to get a connection, so it's possible they were working, just
> taking horribly long to connect. Timeouts for Nagios monitoring PG was
> 10 seconds; pools were 20 seconds.

In that case, the "multiple postmasters" were probably backends spawned
in response to JDBC connection attempts, which went away when they
noticed the client had disconnected. These symptoms seem consistent
with the idea that backend startup was taking a real long time, which
given the context has to be blamed on a DNS lookup timing out. Do you
have log_hostname enabled? If so, the backends would be trying to do
reverse lookups on the IP address of their connected client, and we
could explain all the facts with the assumption that that lookup was
encountering a 30-second-or-so timeout.

Why this should be happening after you change resolv.conf isn't real
clear to me, but in any case if you have a gripe about it you should
gripe to your libc or libbind supplier, not us. Whatever the problem
is, it's down inside the getnameinfo() library routine.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-12-02 15:15:04 Re: deadlock on the same relation
Previous Message Howard Cole 2005-12-02 14:02:55 Unicode Corruption and upgrading to 8.0.4. to 8.1