On Fri, Jun 10, 2011 at 12:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I've been able to reproduce this on released Fedora 15, and sure enough
> it is a compiler bug. The problem comes from these fragments of
> ReadRecord():
> [ ... ]
Whoa, awesome. I spent a few more hours comparing the assembly-- then
I tried compiling a subset of xlog.c with some educated guesses as to
what function might be getting mis-compiled. Obviously my guesses were
not educated enough! :-)
> I've filed a bug report for this:
> https://bugzilla.redhat.com/show_bug.cgi?id=712480
> but I wouldn't care to hold my breath while waiting for a fix to appear
> upstream, let alone propagate to all the distros already using 4.6.0.
I wouldn't hold my breath either.
> I think we need a workaround.
>
> The obvious question to ask here is why are we updating
> "tmpRecPtr.xrecoff" and not "RecPtr->xrecoff"? The latter choice would
> be a lot more readable, since the immediately surrounding code doesn't
> refer to tmpRecPtr. I think the idea is to guarantee that the caller's
> referenced record pointer (if any) isn't modified, but if RecPtr is not
> pointing at tmpRecPtr here, we have got big problems anyway.
Hrm, Couldn't we change all the references to tmpRecPtr to use RecPtr
instead? (Except of course where we assign RecPtr = &tmpRecPtr); I
think that would make the code look a lot less confused. Something
like the attached?
FYI Im happy to test whatever you fix you propose for a few days on
this machine. It gets a fair amount of traffic... hopefully enough to
exercise some possible corner cases.