Re: [HACKERS] uh-oh, dugong failing again
Tom Lane [EMAIL PROTECTED] writes: The PGBuildfarm member dugong had the following event on branch HEAD: Status changed from OK to ContribCheck failure The snapshot timestamp for the build that triggered this notification is: 2007-09-25 20:05:01 This seems to be exactly what we saw two weeks ago, and I just noticed that in the JIT bgwriter patch, I put an Assert into ForwardFsyncRequest in exactly the place where one was removed to make icc happy two weeks ago. This one is less cosmetic and so I'm not as willing to just take it out. I think we need to look closer. Can we confirm that ForwardFsyncRequest somehow becomes a no-op when icc compiles it with an Assert right there? It seems to work with icc on my 32 bit intel cpu. Earlier you speculated that the struct might be getting padded out which would cause hash failures. But surely using a different padding from other compilers would be a compiler bug since it would be an incompatible ABI change. I find it hard to believe intel's compiler would get the ia64 ABI wrong. And hard to believe nobody's noticed an incompatible ABI from gcc-generated binaries. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] uh-oh, dugong failing again
Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: This seems to be exactly what we saw two weeks ago, and I just noticed that in the JIT bgwriter patch, I put an Assert into ForwardFsyncRequest in exactly the place where one was removed to make icc happy two weeks ago. This one is less cosmetic and so I'm not as willing to just take it out. I think we need to look closer. Can we confirm that ForwardFsyncRequest somehow becomes a no-op when icc compiles it with an Assert right there? It seems to work with icc on my 32 bit intel cpu. Earlier you speculated that the struct might be getting padded out which would cause hash failures. But surely using a different padding from other compilers would be a compiler bug since it would be an incompatible ABI change. I find it hard to believe intel's compiler would get the ia64 ABI wrong. And hard to believe nobody's noticed an incompatible ABI from gcc-generated binaries. Well, I changed the Assert() to an explicit if-test-and-elog, and the failure seems to have gone away. So I'd say that makes it absolutely certainly an icc bug. Not clear what difference icc sees between an enabled Assert and an if/elog, but evidently there is one. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] uh-oh, dugong failing again (was Re: Pgbuildfarm-status-green Digest, Vol 28, Issue 24)
The PGBuildfarm member dugong had the following event on branch HEAD: Status changed from OK to ContribCheck failure The snapshot timestamp for the build that triggered this notification is: 2007-09-25 20:05:01 This seems to be exactly what we saw two weeks ago, and I just noticed that in the JIT bgwriter patch, I put an Assert into ForwardFsyncRequest in exactly the place where one was removed to make icc happy two weeks ago. This one is less cosmetic and so I'm not as willing to just take it out. I think we need to look closer. Can we confirm that ForwardFsyncRequest somehow becomes a no-op when icc compiles it with an Assert right there? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
