Thread: pg_getnameinfo_all() failed: Temporary failure in name resolution
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
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?
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
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.
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.
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
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. 😞