Обсуждение: test failure on latest source
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
Regards
Marco
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
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
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 worksAll 135 tests passed. - same test, few days ago, on trunk was fine so it is only failing on recent trunk Regards Marco
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
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
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
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
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
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
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&m=117752314512877&w=2 -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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&m=117752314512877&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. >
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
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
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