Обсуждение: 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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
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
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)? On 10/31/05, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings >
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