Re: gcc 4.6 and hot standby
От | Alex Hunsaker |
---|---|
Тема | Re: gcc 4.6 and hot standby |
Дата | |
Msg-id | BANLkTi=Ys9OVhVmtpSXD7Bxw8GdJo_xTwQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: gcc 4.6 and hot standby (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: gcc 4.6 and hot standby
|
Список | pgsql-hackers |
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.
Вложения
В списке pgsql-hackers по дате отправления: