test failure on latest source

On 2014-04-12 18:39:54 +0200, Marco Atzeri wrote:

LOG: invalid IP address "127.0.0.1": Non-recoverable failure in name
resolution

That sounds like a local setup problem. Is 127.0.0.1 pingable?

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 04/12/2014 12:39 PM, Marco Atzeri wrote:

Anyone seeing similar failure ?

testing on latest

$ git log |head
commit 3c41b812c5578fd7bd5c2de42941012d7d56dde2
Author: Bruce Momjian <bruce@momjian.us>
Date: Thu Apr 10 17:16:22 2014 -0400

docs: psql '--' comments are not passed to the server

C-style block comments are passed to the server.

$ cat /pub/devel/postgresql/prova/build_orig/src/test/regress
/log/postmaster.log
LOG: could not resolve "localhost": Non-recoverable failure in name
resolution
LOG: disabling statistics collector for lack of working socket
WARNING: autovacuum not started because of misconfiguration
HINT: Enable the "track_counts" option.
LOG: invalid IP address "127.0.0.1": Non-recoverable failure in name
resolution
CONTEXT: line 86 of configuration file
"/pub/devel/postgresql/prova/build_orig/src/test/regress/./tmp_check/data/pg_hba.conf"
FATAL: could not load pg_hba.conf

built as usual on cygwin with
../postgresql_orig/configure LDFLAGS=-Wl,-no-undefined --enable-nls
--with-openssl --with-perl --with-python --with-ldap

Why can't it resolve "localhost"? That's a local issue you need to fix.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 12/04/2014 19:11, Andrew Dunstan wrote:

Why can't it resolve "localhost"? That's a local issue you need to fix.

cheers

andrew

Andrew,
just to be clear

- localhost is resolved to 127.0.0.1

- 127.0.0.1 is pingable

- same test on 9.3.4 works
All 135 tests passed.

- same test, few days ago, on trunk was fine

so it is only failing on recent trunk

Regards
Marco

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote:

On 12/04/2014 19:11, Andrew Dunstan wrote:

Why can't it resolve "localhost"? That's a local issue you need to fix.

cheers

andrew

Andrew,
just to be clear

- localhost is resolved to 127.0.0.1

- 127.0.0.1 is pingable

- same test on 9.3.4 works
All 135 tests passed.

- same test, few days ago, on trunk was fine

so it is only failing on recent trunk

Does it work on a commit before
fc752505a99a4e2c781a070d3d42a25289c22e3c?
E.g. f33a71a7865a1dd54f04b370e2637f88665f8db8?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 12/04/2014 19:48, Andres Freund wrote:

On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote:

- same test, few days ago, on trunk was fine

so it is only failing on recent trunk

Does it work on a commit before
fc752505a99a4e2c781a070d3d42a25289c22e3c?
E.g. f33a71a7865a1dd54f04b370e2637f88665f8db8?

f33a71a7865a1dd54f04b370e2637f88665f8db8
works.

Greetings,

Andres Freund

I will look on bisecting from there

Regards
Marco

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andres Freund <andres@2ndquadrant.com> writes:

On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote:

so it is only failing on recent trunk

Does it work on a commit before
fc752505a99a4e2c781a070d3d42a25289c22e3c?

In principle, that commit shouldn't have affected behavior for pg_hba
entries with numeric address fields ...

Is this failure occurring with the default contents of pg_hba.conf,
or have you changed it? If so, how?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2014-04-12 16:35:48 -0400, Tom Lane wrote:

Andres Freund <andres@2ndquadrant.com> writes:

On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote:

so it is only failing on recent trunk

Does it work on a commit before
fc752505a99a4e2c781a070d3d42a25289c22e3c?

In principle, that commit shouldn't have affected behavior for pg_hba
entries with numeric address fields ...

Hm. getaddrinfo.c has this bit:
/* Unsupported flags. */
if (flags & NI_NAMEREQD)
return EAI_AGAIN;

Not sure if that explains anything, but it at the very least seems
problematic for other cases given that flag is now always used...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andres Freund <andres@2ndquadrant.com> writes:

On 2014-04-12 16:35:48 -0400, Tom Lane wrote:

In principle, that commit shouldn't have affected behavior for pg_hba
entries with numeric address fields ...

Hm. getaddrinfo.c has this bit:
/* Unsupported flags. */
if (flags & NI_NAMEREQD)
return EAI_AGAIN;

Yeah, and that flag is only ever specified when attempting to do reverse
lookup on a client address to see if it matches a non-numeric pg_hba
entry.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 13/04/2014 18:09, Tom Lane wrote:

Andres Freund <andres@2ndquadrant.com> writes:

On 2014-04-12 16:35:48 -0400, Tom Lane wrote:

In principle, that commit shouldn't have affected behavior for pg_hba
entries with numeric address fields ...

Hm. getaddrinfo.c has this bit:
/* Unsupported flags. */
if (flags & NI_NAMEREQD)
return EAI_AGAIN;

Yeah, and that flag is only ever specified when attempting to do reverse
lookup on a client address to see if it matches a non-numeric pg_hba
entry.

regards, tom lane

just to recap, as I think no one have yet proposed/implemented
a solution.

first failure I see on cygwin is from
-------------------------------------
$ git log |head
commit fc752505a99a4e2c781a070d3d42a25289c22e3c
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed Apr 2 17:11:24 2014 -0400

Fix assorted issues in client host name lookup.
[cut]
-------------------------------------------

previous one is fine
------------------------------------------
commit f33a71a7865a1dd54f04b370e2637f88665f8db8
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed Apr 2 14:30:08 2014 -0400

De-anonymize the union in JsonbValue.

Needed for strict C89 compliance.
--------------------------------------------

error log
--------------------------------------------
cat
/pub/devel/postgresql/prova/build_orig/src/test/regress/log/postmaster.log
LOG: could not resolve "localhost": Non-recoverable failure in name
resolution
LOG: disabling statistics collector for lack of working socket
WARNING: autovacuum not started because of misconfiguration
HINT: Enable the "track_counts" option.
LOG: invalid IP address "127.0.0.1": Non-recoverable failure in name
resolution
CONTEXT: line 86 of configuration file
"/pub/devel/postgresql/prova/build_orig/src/test/regress/./tmp_check/data/pg_hba.conf"
FATAL: could not load pg_hba.conf
-----------------------------------------------

and of course localhost and 127.0.0.1 are valid

$ ping localhost

Pinging GE-MATZERI-EU [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
[cut]

$ ping 127.0.0.1

Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Marco Atzeri wrote:

On 13/04/2014 18:09, Tom Lane wrote:

Andres Freund <andres@2ndquadrant.com> writes:

On 2014-04-12 16:35:48 -0400, Tom Lane wrote:

In principle, that commit shouldn't have affected behavior for pg_hba
entries with numeric address fields ...

Hm. getaddrinfo.c has this bit:
/* Unsupported flags. */
if (flags & NI_NAMEREQD)
return EAI_AGAIN;

Yeah, and that flag is only ever specified when attempting to do reverse
lookup on a client address to see if it matches a non-numeric pg_hba
entry.

I don't know if this is relevant, but perhaps we're defining the
constants in a way that conflicts with the values defined by cygwin. A
very quick search finds a 2007 patch for Mutt[1]http://marc.info/?l=mutt-dev&amp;m=117752314512877&amp;w=2 that seems to have
NI_NAMEREQD defined as 8 somewhere, while 4 is NI_NOFQDN. But we have
this in getaddrinfo.h:

#ifndef NI_NAMEREQD
#define NI_NAMEREQD 4
#endif

So maybe we're doing something wrong. Indeed, my system has in
/usr/include/netdb.h

# define NI_NAMEREQD 8 /* Don't return numeric addresses. */

You'd do well to research this more, I think.

[1]: http://marc.info/?l=mutt-dev&amp;m=117752314512877&amp;w=2

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 16/04/2014 17:14, Alvaro Herrera wrote:

Marco Atzeri wrote:

On 13/04/2014 18:09, Tom Lane wrote:

Andres Freund <andres@2ndquadrant.com> writes:

On 2014-04-12 16:35:48 -0400, Tom Lane wrote:

In principle, that commit shouldn't have affected behavior for pg_hba
entries with numeric address fields ...

Hm. getaddrinfo.c has this bit:
/* Unsupported flags. */
if (flags & NI_NAMEREQD)
return EAI_AGAIN;

Yeah, and that flag is only ever specified when attempting to do reverse
lookup on a client address to see if it matches a non-numeric pg_hba
entry.

I don't know if this is relevant, but perhaps we're defining the
constants in a way that conflicts with the values defined by cygwin. A
very quick search finds a 2007 patch for Mutt[1] that seems to have
NI_NAMEREQD defined as 8 somewhere, while 4 is NI_NOFQDN. But we have
this in getaddrinfo.h:

#ifndef NI_NAMEREQD
#define NI_NAMEREQD 4
#endif

So maybe we're doing something wrong. Indeed, my system has in
/usr/include/netdb.h

# define NI_NAMEREQD 8 /* Don't return numeric addresses. */

You'd do well to research this more, I think.

[1] http://marc.info/?l=mutt-dev&amp;m=117752314512877&amp;w=2

on cygwin both 32 and 64 bit I see

netdb.h:#define NI_NAMEREQD 0x4 /* Not being able to resolve is
an error. */

same on
w32api/ws2tcpip.h:#define NI_NAMEREQD 0x04

curiosly I see also on
roken-common.h:#define NI_NAMEREQD 0x02

$ cygcheck -f /usr/include/roken-common.h
libkrb5-devel-1.5.3-1

not sure if it has any relevance at all in this case.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

I don't know if this is relevant, but perhaps we're defining the
constants in a way that conflicts with the values defined by cygwin.

Hm, that's a thought, though I still don't see how it's relevant to the
reported failure. Perhaps Cygwin is defining these constants somewhere
other than <netdb.h>? Because getaddrinfo.h definitely pulls that one
in first.

The bigger picture though is that this code isn't failing on the
buildfarm. So what we need to ask is what's different about Marco's
machine.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 16/04/2014 17:40, Tom Lane wrote:

The bigger picture though is that this code isn't failing on the
buildfarm. So what we need to ask is what's different about Marco's
machine.

good question.
I checked again and I found that the fault is only on
the cygwin 64 bit build but not on the cygwin 32 bit one.

I was sure to have tested both, but it seems this time
I missed the comparison.

regards, tom lane

Regards
Marco

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 16/04/2014 18:55, Marco Atzeri wrote:

On 16/04/2014 17:40, Tom Lane wrote:

The bigger picture though is that this code isn't failing on the
buildfarm. So what we need to ask is what's different about Marco's
machine.

good question.
I checked again and I found that the fault is only on
the cygwin 64 bit build but not on the cygwin 32 bit one.

I was sure to have tested both, but it seems this time
I missed the comparison.

regards, tom lane

Regards
Marco

to close the issue, we have identified the fault in the getaddrinfo
system call on cygwin64.

"What happens is that the field ai_addrlen is defined as socklen_t in
POSIX, but as size_t in the W32 API. On 64 bit, socklen_t is 4 bytes
while size_t is 8 bytes.
Setting all the hintp members manually (in
contrast to calloc'ing it or memset'ing it to 0) leaves the 4 upper
bytes of the ai_addrlen untouched. This in turn leads to a high
probability that ai_addrlen has an invalid value when entering
Winsock's getsockopt."

Regards
Marco

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers