Re: Curious buildfarm failures (fwd)

On 2013-01-15 17:56:40 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > I played a bit arround (thanks Sergey!) and it seems to be some rather
> > strange optimization issue around the fsync request queue.
>
> > Namely changing
> > request->rnode = rnode;
> > into
> > request->rnode.spcNode = rnode.spcNode;
> > request->rnode.dbNode = rnode.dbNode;
> > request->rnode.relNode = rnode.relNode;
> > makes it pass reliably.
>
> Jeez. That's my candidate for weird compiler bug of the month.
>
> > How the hell thats correlating with the elog changes I don't yet know.
>
> There is an elog(ERROR) further up in the same function, but it's sure
> not clear how that could cause the compiler to misimplement a struct
> assignment.

Indeed, replacing the elog() there with a plain abort() or the old-style
elog definition makes it work. Just using a do-while with the old
definition inside makes it fail.

My IA64 knowledge is pretty basic, but I would guess this is stack or
code alignment related I seem to remember quite some strange
requirements there.

> Maybe the problem is not in those lines alone, but the fact
> that rnode is a pass-by-value struct? (That is, maybe it's the value of
> the rnode local variable that's getting munged, somewhere up near the
> elog call?)

No, I found this because I printed the values before enquing the values
into shmem and after dequeing. After noticing that they didn't match I
added more...

> We tend to not use pass-by-value struct params much, so we
> might not have noticed a compiler bug associated with that. Or IOW,
> does changing ForwardFsyncRequest to use a "const RelFileNode *rnode"
> parameter make it go away?

Nope, same thing.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services