Skip site navigation (1) Skip section navigation (2)

Re: Ident authentication fails due to bind error on server (8.4.8)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marinos Yannikos" <mjy(at)geizhals(dot)at>
Cc: "PostgreSQL Bugs" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Ident authentication fails due to bind error on server (8.4.8)
Date: 2011-06-17 17:51:59
Message-ID: 20339.1308333119@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
I wrote:
> I don't think it's a race condition per se.  The code ought to be
> setting up the address argument for bind() with sin_port = 0 so that
> an unused port number gets assigned.  That seems to be what happens on
> a couple of machines that I tried here, but I notice that the Linux
> manpage for getaddrinfo says

> 	service sets the port in each returned address structure.  If
> 	this argument is a service name (see services(5)), it is
> 	translated to the corresponding port number.  This argument can
> 	also be specified as a decimal number, which is simply converted
> 	to binary.  If service is NULL, then the port number of the
> 	returned socket addresses will be left uninitialized.

> In principle this wording would allow getaddrinfo to return the same
> nonzero port number in multiple backends, which would lead to the
> reported failure if they were doing ident verification at the same time.
> I'm thinking maybe we should explicitly pass "0" rather than NULL to
> getaddrinfo here.  On the other hand, it seems to work reliably as-is
> on my Linux machine, so this is just speculation at this point.

I looked at the glibc source code for getaddrinfo, and it looks like
they do reliably set sin_port to zero when no service argument is
provided, despite the above documentation statement.  So that's why it
works for me.  But still, if you're on a non-Linux platform it seems
possible that this is the mechanism for what's biting you.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Robert HaasDate: 2011-06-17 18:48:05
Subject: Re: Behaviour of triggers on replicated and non replicated tables
Previous:From: Merlin MoncureDate: 2011-06-17 17:24:34
Subject: Re: could not read block XXXXX in file "base/YYYYY/ZZZZZZ": read only 160 of 8192 bytes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group