8.1 Release Candidate 1 Coming ...

On 29/10/05 4:47 am, "Marc G. Fournier" <scrappy@postgresql.org> 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

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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

Tom Lane wrote:

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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

tgl@sss.pgh.pa.us (Tom Lane) writes:

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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

Chris Browne <cbbrowne@acm.org> writes:

tgl@sss.pgh.pa.us (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

Is this issue only on AIX 5.3 ML1 thru ML 3?
Does the build work fine with 5.2 (ALL MLs)?

Mag Gam <magawake@gmail.com> 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

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