Re: gcc 4.6 and hot standby
Alex Hunsaker <badalex@gmail.com>
From: Alex Hunsaker <badalex@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
Date: 2011-06-10T20:00:26Z
Lists: pgsql-hackers
Attachments
- gcc46_xlog.patch (text/x-patch) patch
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.