On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > FWIW its also triggerable if two other function calls are places inside
> > the above if() (I tried fprintf(stderr, "argh") and kill(0, 0)).
>
> [ confused... ] You mean replacing the abort() in the elog macro with
> one of these functions? Or something else?
I mean replacing the elog(ERROR, "ForwardFsyncRequest must...") with any
two function calls inside a do/while(0). I just tried to place some
random functions there instead of the elog to make sure its unrelated,
and it still triggers the problem even before the elog commit. The
assembler output of that function changes wildly with tiny changes and I
don't understand IA-64 at all (does anybody?), so I don't see anything
we can do there.
> > It seems the change just made an existing issue visible.
> > No idea what to do about it.
>
> Pretty clearly a compiler bug at this point. Since there doesn't seem
> to be a clean workaround (no, I don't want to expand the struct
> assignment manually), and anyway we can't be sure that the bug doesn't
> also manifest in other places, recommending Sergey update his compiler
> seems like the thing to do.
Yea. Don't have a better suggestion.
> At this point I'm more interested in his report in
> <alpine.LRH.2.03.1301152012220.773@ast.cam.ac.uk> about
> the Assert at spgdoinsert.c:1222 failing. That's pretty new code, so
> more likely to have a genuine bug, and I wonder if it's related to
> the spgist issue in <50EBF992.2000704@qunar.com> ...
Yes, it looks more like it could be something real. There are
suspicously many other failing tests though (misc, with) that don't seem
to be related to the spgist crash.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services