Thread: Problem with listen_addresses = '*' on 8.4beta2 on AIX
Building 8.4beta2 on my AIX test machine works fine, but when I set listen_addresses = '*' in postgresql.conf, the server fails to start. This is what I get: LOG: 00000: could not translate service "5432" to address: Hostname and service name not provided or found LOCATION: StreamServerPort, pqcomm.c:294 WARNING: 01000: could not create listen socket for "*" LOCATION: PostmasterMain, postmaster.c:843 FATAL: XX000: could not create any TCP/IP sockets LOCATION: PostmasterMain, postmaster.c:848 It works fine if listen_addresses is the empty string or the hostname, only with the asterisk it seems to fail. These are the relevant entries in postgresql.conf: listen_addresses = '*' port = 5432 Relevant parts of pg_config: CONFIGURE = '--prefix=/postgres/8.4' '--with-includes=/usr/local/include' '--with-libraries=/usr/local/lib' '--enable-debug''--enable-cassert' '--with-ldap' '--without-readline' '--enable-integer-datetimes' '--without-zlib' '--enable-thread-safety''CC=gcc -maix64' 'LDFLAGS=-Wl,-bbigtoc' CC = gcc -maix64 CPPFLAGS = -I/usr/local/include CFLAGS = -O0 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g CFLAGS_SL = LDFLAGS = -Wl,-bbigtoc -L/usr/local/lib -Wl,-blibpath:/postgres/8.4/lib:/usr/local/lib:/usr/lib:/lib LDFLAGS_SL = -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE LIBS = -lpgport -lld -lm VERSION = PostgreSQL 8.4beta2 The operating system is AIX 5.3 ML 03. This change must have broken the code: http://archives.postgresql.org/pgsql-committers/2009-01/msg00297.php If listen_addresses is *, then getaddrinfo() will be called with NULL for both the first and the second argument, which is not allowed according to the documentation: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.commtechref/doc/commtrf2/getaddrinfo.htm and should and does return EAI_NONAME = 8. I guess that the buildfarm did not fail because it does not use '*'. Yours, Laurenz Albe
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> Building 8.4beta2 on my AIX test machine works fine,
> but when I set listen_addresses = '*' in postgresql.conf,
> the server fails to start.
I grow weary of AIX's seemingly-unlimited supply of getaddrinfo
peculiarities. What about forgetting the whole matter and always
using our src/port/ implementation on that OS?
regards, tom lane
Tom Lane wrote: > "Albe Laurenz" <laurenz.albe@wien.gv.at> writes: > >> Building 8.4beta2 on my AIX test machine works fine, >> but when I set listen_addresses = '*' in postgresql.conf, >> the server fails to start. >> > > I grow weary of AIX's seemingly-unlimited supply of getaddrinfo > peculiarities. What about forgetting the whole matter and always > using our src/port/ implementation on that OS? > > > I'm assuming that the OP has tested that 8.3 works on the same machine with listen_addresses = '*'. If so, then this seems a reasonable suggestion. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> I grow weary of AIX's seemingly-unlimited supply of getaddrinfo
>> peculiarities. What about forgetting the whole matter and always
>> using our src/port/ implementation on that OS?
> I'm assuming that the OP has tested that 8.3 works on the same machine
> with listen_addresses = '*'.
> If so, then this seems a reasonable suggestion.
The only serious knock I can see on our implementation is that it lacks
IPv6 support. So we'd not want to use it on AIX versions that are
IPv6-capable. Which are those, if any, and do they have any of these
getaddrinfo issues?
regards, tom lane
On Tue, Jun 9, 2009 at 5:24 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Tom Lane wrote: >>> I grow weary of AIX's seemingly-unlimited supply of getaddrinfo >>> peculiarities. What about forgetting the whole matter and always >>> using our src/port/ implementation on that OS? > >> I'm assuming that the OP has tested that 8.3 works on the same machine >> with listen_addresses = '*'. >> If so, then this seems a reasonable suggestion. > > The only serious knock I can see on our implementation is that it lacks > IPv6 support. So we'd not want to use it on AIX versions that are > IPv6-capable. Which are those, if any, and do they have any of these > getaddrinfo issues? actually, aix was the first commercial unix distribution to support ipv6 afaik...as of 4.3 iirc. merlin
Merlin Moncure <mmoncure@gmail.com> writes:
> Tom Lane wrote:
>> The only serious knock I can see on our implementation is that it lacks
>> IPv6 support. �So we'd not want to use it on AIX versions that are
>> IPv6-capable. �Which are those, if any, and do they have any of these
>> getaddrinfo issues?
> actually, aix was the first commercial unix distribution to support
> ipv6 afaik...as of 4.3 iirc.
Drat. Okay, that easy solution probably won't fly. Anyone with AIX
access want to try to develop a patch that covers this case without
breaking the other ones?
regards, tom lane
Tom Lane wrote: > Drat. Okay, that easy solution probably won't fly. Anyone with AIX > access want to try to develop a patch that covers this case without > breaking the other ones? I can try, but I only have AIX 5.3 to test with, so I won't be able to test for bugs in other versions. I would need to know what the problems with getaddrinfo on AIX are. Is this an exhaustive list? http://archives.postgresql.org/pgsql-hackers/2009-01/msg01705.php http://archives.postgresql.org/pgsql-hackers/2006-10/msg01069.php http://archives.postgresql.org/pgsql-general/2006-10/msg00909.php http://archives.postgresql.org/pgsql-hackers/2004-07/msg01018.php http://archives.postgresql.org/pgsql-hackers/2004-04/msg00474.php I'll also try to investigate known bugs in AIX' getaddrinfo. AIX 4.3 has been out of support for some time - if it makes the task easier, would it be an option to desupport it? Yours, Laurenz Albe
On Wed, Jun 10, 2009 at 3:38 AM, Albe Laurenz<laurenz.albe@wien.gv.at> wrote: > Tom Lane wrote: >> Drat. Okay, that easy solution probably won't fly. Anyone with AIX >> access want to try to develop a patch that covers this case without >> breaking the other ones? > > I can try, but I only have AIX 5.3 to test with, so I won't be able > to test for bugs in other versions. > > I would need to know what the problems with getaddrinfo on AIX are. > Is this an exhaustive list? > http://archives.postgresql.org/pgsql-hackers/2009-01/msg01705.php > http://archives.postgresql.org/pgsql-hackers/2006-10/msg01069.php > http://archives.postgresql.org/pgsql-general/2006-10/msg00909.php > http://archives.postgresql.org/pgsql-hackers/2004-07/msg01018.php > http://archives.postgresql.org/pgsql-hackers/2004-04/msg00474.php > > I'll also try to investigate known bugs in AIX' getaddrinfo. > > AIX 4.3 has been out of support for some time - if it makes the > task easier, would it be an option to desupport it? We have 4.3 and a 6.0 here. 4.3 is pretty old, I don't think it's a big deal if we can't get it to work, as long as libpq works. merlin
Merlin Moncure wrote: > I wrote: >> I can try, but I only have AIX 5.3 to test with, so I won't be able >> to test for bugs in other versions. >> >> I would need to know what the problems with getaddrinfo on AIX are. >> >> I'll also try to investigate known bugs in AIX' getaddrinfo. >> >> AIX 4.3 has been out of support for some time - if it makes the >> task easier, would it be an option to desupport it? > > We have 4.3 and a 6.0 here. 4.3 is pretty old, I don't think it's a > big deal if we can't get it to work, as long as libpq works. Ok, I did a bit of research here. First, the only cases that affect us are the following: a) listen_addresses = '*' Then the "hostname" argument to getaddrinfo will be NULL, and the "servname" argument will be"5432" or similar. b) listen_addresses = '' This does not affect us, since it will not call getaddrinfo. c) listen_addresses = 'host1[,...]' Then the "hostname" argument will be host1 (DNS name or IPv4/6 address), and "servname"will be "5432" or similar. Moreover, in the struct addrinfo "hint", the following will be set: ai_flags = AI_PASSIVE ai_family = AF_UNSPEC ai_socktype= SOCK_STREAM and all other hints will be zero. Did I cover all cases? I tested getaddrinfo() on my AIX 5.3 ML 03 with these cases, and I did not encounter any problems and the result looked right. I searched the bug database at IBM, and the only APARs that looked like they might affect us are: IY40908, IY45130 = IY44782, IY47326 = IY46612 = IY48232, IY46023, IY51966 = IY50970, IY54776, IZ00799 and IY86414 = IY86549. Since it works on my system, I wonder if the machines where it fails did not have any fixpacks installed. Does Andrew Chernow's machine have the terminal fixpack installed? I wonder what problem he encountered when he said "the service argument to getaddrinfo is busted on AIX 4.3". Maybe it would be good enough to state that AIX is only supported with certain fixpacks installed? And do without all the AIX hacks? Yours, Laurenz Albe
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> Maybe it would be good enough to state that AIX is only supported with
> certain fixpacks installed? And do without all the AIX hacks?
That would definitely be a good-enough solution in my opinion,
as long as we can document which fixes are needed for which releases.
regards, tom lane
On Wed, Jun 10, 2009 at 12:13 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > "Albe Laurenz" <laurenz.albe@wien.gv.at> writes: >> Maybe it would be good enough to state that AIX is only supported with >> certain fixpacks installed? And do without all the AIX hacks? > > That would definitely be a good-enough solution in my opinion, > as long as we can document which fixes are needed for which releases. my take is to go with Albe's solution. I'm downloading the cumulative fixpack for 4.3.3: http://www14.software.ibm.com/webapp/set2/sas/f/aix433fixes/ml11package.html If the above fixes the problem with the aix hacks removed, problem solved. If it doesn't, then let's face the music and formally drop support for aix 4.3 for 8.4. (and, other than that, do nothing). merlin
Merlin Moncure wrote: > On Wed, Jun 10, 2009 at 12:13 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > >> "Albe Laurenz" <laurenz.albe@wien.gv.at> writes: >> >>> Maybe it would be good enough to state that AIX is only supported with >>> certain fixpacks installed? And do without all the AIX hacks? >>> >> That would definitely be a good-enough solution in my opinion, >> as long as we can document which fixes are needed for which releases. >> > > my take is to go with Albe's solution. I'm downloading the cumulative > fixpack for 4.3.3: > > http://www14.software.ibm.com/webapp/set2/sas/f/aix433fixes/ml11package.html > > If the above fixes the problem with the aix hacks removed, problem > solved. If it doesn't, then let's face the music and formally drop > support for aix 4.3 for 8.4. (and, other than that, do nothing). > You mean nothing other than removing the AIX hacks? (I'm with Tom. This has been a constant annoyance over quite a few years.) cheers andrew
Merlin Moncure <mmoncure@gmail.com> writes: >> "Albe Laurenz" <laurenz.albe@wien.gv.at> writes: >>> Maybe it would be good enough to state that AIX is only supported with >>> certain fixpacks installed? And do without all the AIX hacks? > my take is to go with Albe's solution. I'm downloading the cumulative > fixpack for 4.3.3: > http://www14.software.ibm.com/webapp/set2/sas/f/aix433fixes/ml11package.html > If the above fixes the problem with the aix hacks removed, problem > solved. If it doesn't, then let's face the music and formally drop > support for aix 4.3 for 8.4. (and, other than that, do nothing). Where are we on this? regards, tom lane
On Thu, Jun 11, 2009 at 9:50 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > Merlin Moncure <mmoncure@gmail.com> writes: >>> "Albe Laurenz" <laurenz.albe@wien.gv.at> writes: >>>> Maybe it would be good enough to state that AIX is only supported with >>>> certain fixpacks installed? And do without all the AIX hacks? > >> my take is to go with Albe's solution. I'm downloading the cumulative >> fixpack for 4.3.3: > >> http://www14.software.ibm.com/webapp/set2/sas/f/aix433fixes/ml11package.html > >> If the above fixes the problem with the aix hacks removed, problem >> solved. If it doesn't, then let's face the music and formally drop >> support for aix 4.3 for 8.4. (and, other than that, do nothing). > > Where are we on this? waiting on a patch? Albe? (or should I do it myself?) merlin
Merlin Moncure <mmoncure@gmail.com> writes:
> On Thu, Jun 11, 2009 at 9:50 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> Where are we on this?
> waiting on a patch? Albe? (or should I do it myself?)
I thought the proposed patch was just "remove the special case for AIX
in src/backend/libpq/ip.c".
regards, tom lane
Tom Lane wrote: >> On Thu, Jun 11, 2009 at 9:50 AM, Tom Lane wrote: >>> Where are we on this? > >> waiting on a patch? Albe? (or should I do it myself?) > > I thought the proposed patch was just "remove the special case for AIX > in src/backend/libpq/ip.c". Yes. The only bugs at IBM that are listed as open are IZ43766 = IZ44519, and they should not affect us (I looked through the code). For the record, these result in ai_socktype and ai_protocol being set to zero in the result. All other problems should be fixed in AIX 6.1 ML 02, AIX 5.3 ML 09 and AIX 5.2 ML 09. It's hard to say for AIX 5.1 and AIX 4.3.3 as they are out of support, and bugs that are fixed in current versions may be unfixed there. On the other hand, the bugs may have been introduced later. Thus, for AIX 5.1 and AIX 4.3.3 we should request that the last Maintenance Level be installed (ML 09 for AIX 5.1 and ML 11 for 4.3.3). I am waiting for Merlin's report whether getaddrinfo(3) works on his AIX 4.3.3 after upgrading to ML 11. I'll attach a small C program I wrote for my convenience to test different getaddrinfo calls that occur in PostgreSQL code. After we have word from Merlin, I'd write a patch that changes src/backend/libpq/ip.c and src/frontend/libpq/ip.c to undo the AIX hack and adds documentation to section 15.8.1 that states the recommended fix levels per AIX version. I won't get to do that before Monday though, so if somebody can do it before that, go ahead. Which raises a final question for me: The documentation mentions support from 4.3 on, and there are specific comments for 4.3.2. We can't say anything for versions before 4.3.3, can we? Should we drop versions < 4.3.3 even if Merlin reports success for 4.3.3? Yours, Laurenz Albe
Attachment
On Fri, Jun 12, 2009 at 7:42 AM, Albe Laurenz<laurenz.albe@wien.gv.at> wrote: > Which raises a final question for me: > The documentation mentions support from 4.3 on, and there are specific > comments for 4.3.2. > We can't say anything for versions before 4.3.3, can we? > Should we drop versions < 4.3.3 even if Merlin reports success for 4.3.3? 4.3.3 is working fine. merlin
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes: > After we have word from Merlin, I'd write a patch that changes > src/backend/libpq/ip.c and src/frontend/libpq/ip.c to undo the AIX hack > and adds documentation to section 15.8.1 that states the recommended > fix levels per AIX version. > I won't get to do that before Monday though, so if somebody can do > it before that, go ahead. The code change is already made for RC1, but if you want to send in a patch to improve the docs, feel free. I left it with just a vague recommendation to update to the latest fixpack: http://developer.postgresql.org/pgdocs/postgres/installation-platform-notes.html#INSTALLATION-NOTES-AIX regards, tom lane
Tom Lane wrote: > The code change is already made for RC1, but if you want to send in a > patch to improve the docs, feel free. I left it with just a vague > recommendation to update to the latest fixpack: > http://developer.postgresql.org/pgdocs/postgres/installation-platform-notes.html#INSTALLATION-NOTES-AIX The attached patch states that we support 4.3.3 to 6.1, removes the comment for version 4.3.2 and adds a table of minimum recommended fix levels for AIX. Use all or parts of it as you think fit. Yours, Laurenz Albe
Attachment
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> The attached patch states that we support 4.3.3 to 6.1, removes the
> comment for version 4.3.2 and adds a table of minimum recommended fix
> levels for AIX.
Applied with a bit of additional wordsmithing. Thanks!
regards, tom lane