Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
[EMAIL PROTECTED] (Tom Lane) writes: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: hmm well -HEAD(and 8.0.4 too!) is broken on AIX 5.3ML3: http://archives.postgresql.org/pgsql-hackers/2005-10/msg01053.php [ shrug... ] The reports of this problem have not given enough information to fix it, and since it's not a regression from 8.0, it's not going to hold up the 8.1 release. When and if we receive enough info to fix it, we'll gladly do so, but ... Well, we never had an AIX 5.3 system when 8.0 was released, so didn't attempt a compile. Seneca just tried out a build on 8.0.3 on AIX 5.3; it appears to be experiencing the same problem with initdb, and a slight modification of the previous fix appears to resolve the issue. Can you suggest what further we might provide that would help? (My guess is that the problem is a compiler or libc bug anyway, given that one report says that replacing a memcpy call with an equivalent loop makes the failure go away.) It seems unlikely to be a compiler bug as the same issue has been reported with both GCC and IBM XLC. I could believe it being a libc bug... It would be terribly disappointing to have to report both internally and externally that AIX 5.3 is not a usable platform for recent releases of PostgreSQL... -- cbbrowne,@,ntlug.org http://cbbrowne.com/info/linuxdistributions.html Never lend your car to anyone to whom you have given birth to. --Erma Bombeck ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
Chris Browne [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Tom Lane) writes: (My guess is that the problem is a compiler or libc bug anyway, given that one report says that replacing a memcpy call with an equivalent loop makes the failure go away.) It seems unlikely to be a compiler bug as the same issue has been reported with both GCC and IBM XLC. I could believe it being a libc bug... As best I can tell after poking at it on Stefan's machine, it's a linker bug, or else there is something strange about memcpy as compared to, say, memcmp. A function pointer to memcmp works, a function pointer to memcpy contains a bogus value that points entirely outside the program's address space. This despite the assembly code that generates them looking just the same in both cases, viz LC..12: .tc memcmp[TC],memcmp[DS] LC..14: .tc memcpy[TC],memcpy[DS] Even more interesting, if you start the postmaster under gdb and examine the pointer, then set a breakpoint at main and say run, by the time control arrives at main() the bogus value has changed to a different bogus value. So something in the basic C runtime support is frobbing it --- incorrectly :-(. I think all the signs point to incorrect relocation data generated by the linker, though I have no idea why only memcpy would be affected. It would be terribly disappointing to have to report both internally and externally that AIX 5.3 is not a usable platform for recent releases of PostgreSQL... According to Stefan it broke between 5.3ML1 and 5.3ML3. I suggest filing a defect report with IBM. We're not going to stop using memcpy because one version of one platform is broken. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
Is this issue only on AIX 5.3 ML1 thru ML 3? Does the build work fine with 5.2 (ALL MLs)? On 10/31/05, Tom Lane [EMAIL PROTECTED] wrote: Chris Browne [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Tom Lane) writes: (My guess is that the problem is a compiler or libc bug anyway, given that one report says that replacing a memcpy call with an equivalent loop makes the failure go away.) It seems unlikely to be a compiler bug as the same issue has been reported with both GCC and IBM XLC. I could believe it being a libc bug... As best I can tell after poking at it on Stefan's machine, it's a linker bug, or else there is something strange about memcpy as compared to, say, memcmp. A function pointer to memcmp works, a function pointer to memcpy contains a bogus value that points entirely outside the program's address space. This despite the assembly code that generates them looking just the same in both cases, viz LC..12: .tc memcmp[TC],memcmp[DS] LC..14: .tc memcpy[TC],memcpy[DS] Even more interesting, if you start the postmaster under gdb and examine the pointer, then set a breakpoint at main and say run, by the time control arrives at main() the bogus value has changed to a different bogus value. So something in the basic C runtime support is frobbing it --- incorrectly :-(. I think all the signs point to incorrect relocation data generated by the linker, though I have no idea why only memcpy would be affected. It would be terribly disappointing to have to report both internally and externally that AIX 5.3 is not a usable platform for recent releases of PostgreSQL... According to Stefan it broke between 5.3ML1 and 5.3ML3. I suggest filing a defect report with IBM. We're not going to stop using memcpy because one version of one platform is broken. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
Mag Gam [EMAIL PROTECTED] writes: Is this issue only on AIX 5.3 ML1 thru ML 3? Does the build work fine with 5.2 (ALL MLs)? There's an AIX 5.2 machine in the buildfarm, and it seems happy. I have no idea about details beyond that ... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
Mag Gam wrote: Is this issue only on AIX 5.3 ML1 thru ML 3? Does the build work fine with 5.2 (ALL MLs)? 5.3 ML1 works but it is affected by the System include Bug mentioned in our AIX-FAQ. ML3 is supposed to fix that specific problem but breaks in another more difficult way as it seems ... Stefan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
On 29/10/05 4:47 am, Marc G. Fournier [EMAIL PROTECTED] wrote: Tomorrow evening, I'm going to wrap up RC1, to announce it on Monday ... if anyone is sitting on *anything*, please say something before about midnight GMT ... Don't include a link for the Windows version in your email please - I'm on a plane most of the day tomorrow, and won't be fit for anything on Monday I doubt, therefore won't get it built. Regards, Dave ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
Marc G. Fournier wrote: Tomorrow evening, I'm going to wrap up RC1, to announce it on Monday ... if anyone is sitting on *anything*, please say something before about midnight GMT ... hmm well -HEAD(and 8.0.4 too!) is broken on AIX 5.3ML3: http://archives.postgresql.org/pgsql-hackers/2005-10/msg01053.php Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: hmm well -HEAD(and 8.0.4 too!) is broken on AIX 5.3ML3: http://archives.postgresql.org/pgsql-hackers/2005-10/msg01053.php [ shrug... ] The reports of this problem have not given enough information to fix it, and since it's not a regression from 8.0, it's not going to hold up the 8.1 release. When and if we receive enough info to fix it, we'll gladly do so, but ... (My guess is that the problem is a compiler or libc bug anyway, given that one report says that replacing a memcpy call with an equivalent loop makes the failure go away.) regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: hmm well -HEAD(and 8.0.4 too!) is broken on AIX 5.3ML3: http://archives.postgresql.org/pgsql-hackers/2005-10/msg01053.php [ shrug... ] The reports of this problem have not given enough information to fix it, and since it's not a regression from 8.0, it's not going to hold up the 8.1 release. When and if we receive enough info to fix it, we'll gladly do so, but ... (My guess is that the problem is a compiler or libc bug anyway, given that one report says that replacing a memcpy call with an equivalent loop makes the failure go away.) seneca is using gcc 4.0.1, I can reproduce the sig11 with gcc 3.3.2 and the hang with the IBM AIX-compiler so that would indicate a libc-bug ... If somebody is interested I can provide access to my testbox to help in debugging ... Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] 8.1 Release Candidate 1 Coming ...
Tomorrow evening, I'm going to wrap up RC1, to announce it on Monday ... if anyone is sitting on *anything*, please say something before about midnight GMT ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
