Thread: pg_getnameinfo_all() failed: Temporary failure in name resolution

pg_getnameinfo_all() failed: Temporary failure in name resolution

From
Ron Johnson
Date:
PG 9.6.24 (Yes, I know it's EOL.)

I'm seeing lots of these in the postgresql log file:
2023-11-24 15:09:02.224 EST             [unknown]       [unknown]       18163           [unknown]       01000   WARNING:  01000: pg_getnameinfo_all() failed: Temporary failure in name resolution
2023-11-24 15:09:02.224 EST             [unknown]       [unknown]       18163           [unknown]       01000   LOCATION:  BackendInitialize, postmaster.c:4220

What name is postgresql failing to resolve?

Re: pg_getnameinfo_all() failed: Temporary failure in name resolution

From
Adrian Klaver
Date:
On 11/24/23 12:30, Ron Johnson wrote:
> PG 9.6.24 (Yes, I know it's EOL.)
> 
> I'm seeing lots of these in the postgresql log file:
> 2023-11-24 15:09:02.224 EST             [unknown]       [unknown]       
> 18163           [unknown]       01000   WARNING:  01000: 
> pg_getnameinfo_all() failed: Temporary failure in name resolution
> 2023-11-24 15:09:02.224 EST             [unknown]       [unknown]       
> 18163           [unknown]       01000   LOCATION:  BackendInitialize, 
> postmaster.c:4220
> 
> What name is postgresql failing to resolve?

 From ~/src/common/ip.c

/*
  *      pg_getnameinfo_all - get name info for Unix, IPv4 and IPv6 sockets
  *
  * The API of this routine differs from the standard getnameinfo() 
definition
  * in two ways: first, the addr parameter is declared as sockaddr_storage
  * rather than struct sockaddr, and second, the node and service fields are
  * guaranteed to be filled with something even on failure return.
  */


-- 
Adrian Klaver
adrian.klaver@aklaver.com




Re: pg_getnameinfo_all() failed: Temporary failure in name resolution

From
Ron Johnson
Date:
On Fri, Nov 24, 2023 at 3:46 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 11/24/23 12:30, Ron Johnson wrote:
> PG 9.6.24 (Yes, I know it's EOL.)
>
> I'm seeing lots of these in the postgresql log file:
> 2023-11-24 15:09:02.224 EST             [unknown]       [unknown]       
> 18163           [unknown]       01000   WARNING:  01000:
> pg_getnameinfo_all() failed: Temporary failure in name resolution
> 2023-11-24 15:09:02.224 EST             [unknown]       [unknown]       
> 18163           [unknown]       01000   LOCATION:  BackendInitialize,
> postmaster.c:4220
>
> What name is postgresql failing to resolve?

 From ~/src/common/ip.c

/*
  *      pg_getnameinfo_all - get name info for Unix, IPv4 and IPv6 sockets
  *
  * The API of this routine differs from the standard getnameinfo()
definition
  * in two ways: first, the addr parameter is declared as sockaddr_storage
  * rather than struct sockaddr, and second, the node and service fields are
  * guaranteed to be filled with something even on failure return.
  */


The second "way" sounds interesting, but what is it filled with?

I added "log_hostname = on" to postgresql.conf earlier in the day.  When I commented that out, the errors stopped happening.

Re: pg_getnameinfo_all() failed: Temporary failure in name resolution

From
"David G. Johnston"
Date:
On Friday, November 24, 2023, Ron Johnson <ronljohnsonjr@gmail.com> wrote:

The second "way" sounds interesting, but what is it filled with?

What does it matter?  It’s an internal detail that apparently gets exposed as [unknown] appearing in your log file where the client ip address would normally be.
 

I added "log_hostname = on" to postgresql.conf earlier in the day.  When I commented that out, the errors stopped happening.

This makes sense.

David J.
 

Re: pg_getnameinfo_all() failed: Temporary failure in name resolution

From
Ron Johnson
Date:
On Fri, Nov 24, 2023 at 4:26 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Friday, November 24, 2023, Ron Johnson <ronljohnsonjr@gmail.com> wrote:

The second "way" sounds interesting, but what is it filled with?

What does it matter?  It’s an internal detail that apparently gets exposed as [unknown] appearing in your log file where the client ip address would normally be.

Because I'd hope that the log file would tell me the errant host name.  
 

I added "log_hostname = on" to postgresql.conf earlier in the day.  When I commented that out, the errors stopped happening.

This makes sense.

But is not explanatory.  I want to see host names in the log file when possible, not just IP addresses.

In pg_hba.conf. all application servers are either IP addresses, or names that are explicitly defined in /etc/hosts.

Re: pg_getnameinfo_all() failed: Temporary failure in name resolution

From
"Peter J. Holzer"
Date:
On 2023-11-24 16:39:57 -0500, Ron Johnson wrote:
> On Fri, Nov 24, 2023 at 4:26 PM David G. Johnston <david.g.johnston@gmail.com>
> wrote:
>
>     On Friday, November 24, 2023, Ron Johnson <ronljohnsonjr@gmail.com> wrote:
>
>
>         The second "way" sounds interesting, but what is it filled with?

With "???"

(which isn't very helpful. I would have hoped it's filled in with a
representation of the IP address)



>     What does it matter?  It’s an internal detail that apparently gets exposed
>     as [unknown] appearing in your log file where the client ip address would
>     normally be.
>
>
> Because I'd hope that the log file would tell me the errant host name.  

The error message says that the host name could not be determined
because of a DNS error. So obviously it can't tell you the host name.
It could tell you the IP address, though.


>         I added "log_hostname = on" to postgresql.conf earlier in the day. 
>         When I commented that out, the errors stopped happening.
>
>
>     This makes sense.
>
>
> But is not explanatory.  I want to see host names in the log file when
> possible, not just IP addresses.

So now that you have IP addresses again, are there any for which a
reverse lookup doesn't work?

        hp

--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

Attachment

Re: pg_getnameinfo_all() failed: Temporary failure in name resolution

From
Ron Johnson
Date:
On Sun, Nov 26, 2023 at 6:51 AM Peter J. Holzer <hjp-pgsql@hjp.at> wrote:
[snip] 
> But is not explanatory.  I want to see host names in the log file when
> possible, not just IP addresses.

So now that you have IP addresses again, are there any for which a
reverse lookup doesn't work?

I've gone through /etc/hosts, and there are some mismatches between it and DNS.  Maybe that's the cause of the errors... maybe not.  😞