Hi,
On 2013-01-16 01:28:09 -0500, Tom Lane wrote:
It's a compiler bug.
Gah. Not again. Not that I am surprised, but still.
icc 11.1 apparently thinks that this loop in doPickSplit:
(Why does it think it needs to prefetch an array it's only going to
write into? Is IA64's cache hardware
Hi,
On Wed, 16 Jan 2013, Andres Freund wrote:
On 2013-01-16 01:28:09 -0500, Tom Lane wrote:
It's a compiler bug.
Thanks for investigating. But I'm not sure there is any way other way for
me other than switching to gcc, because intel stopped providing their
IA64 version of compilers free of
On 2013-01-16 14:41:47 +, Sergey Koposov wrote:
Hi,
On Wed, 16 Jan 2013, Andres Freund wrote:
On 2013-01-16 01:28:09 -0500, Tom Lane wrote:
It's a compiler bug.
Thanks for investigating. But I'm not sure there is any way other way for me
other than switching to gcc, because intel
On 01/16/2013 09:41 AM, Sergey Koposov wrote:
So unless somebody suggest otherwise, i'm going to switch to gcc on
this buildfarm.
If you switch compiler it should be a new buildfarm animal. (That just
means re-registering so you get a new name/secret pair.) We have
provision for upgrading
On Wed, 16 Jan 2013, Andres Freund wrote:
So unless somebody suggest otherwise, i'm going to switch to gcc on this
buildfarm.
What about switching to -O1 of 11.1?
I don't know. It is up to -hackers to decide. I think that icc on ia64
have shown bugginess time after time. But if you think
Sergey Koposov kopo...@ast.cam.ac.uk writes:
On Wed, 16 Jan 2013, Andres Freund wrote:
What about switching to -O1 of 11.1?
I don't know. It is up to -hackers to decide. I think that icc on ia64
have shown bugginess time after time. But if you think that buildfarm
with icc 11.1 -O1 carry
Hi,
Date: Tue, 15 Jan 2013 11:57:07 -0500
From: Tom Lane t...@sss.pgh.pa.us
To: Andres Freund and...@2ndquadrant.com
Cc: m...@sai.msu.ru, pgsql-hackers@postgreSQL.org,
Andrew Dunstan and...@dunslane.net
Subject: Re: Curious buildfarm failures
Well, it could be quite reproducible, if for
On 2013-01-15 17:27:50 +, Sergey Koposov wrote:
Hi,
Date: Tue, 15 Jan 2013 11:57:07 -0500
From: Tom Lane t...@sss.pgh.pa.us
To: Andres Freund and...@2ndquadrant.com
Cc: m...@sai.msu.ru, pgsql-hackers@postgreSQL.org,
Andrew Dunstan and...@dunslane.net
Subject: Re: Curious buildfarm
On Tue, 15 Jan 2013, Andres Freund wrote:
Any chance you could run make check again but with log_statement=all and
log_min_messages=debug2? That might tell us a bit more, whether the
dependency code doesn't work right or whether the checkpoint is doing
strange things.
Here it is :
2013-01-15
Sergey Koposov kopo...@ast.cam.ac.uk writes:
And I do see the tblspc file left after the finish of make check:
tmp_check/data/pg_tblspc/16385/PG_9.3_201212081/16384/16387
Interesting. If the tests are run immediately after initdb, 16387
is the relfilenode assigned to table foo in the
On Tue, 15 Jan 2013, Tom Lane wrote:
BTW, I just finished trying to reproduce this on an IA64 machine
belonging to Red Hat, without success. So that seems to eliminate
any possibility of the machine architecture being the trigger issue.
The compiler's still a likely cause though.
Anybody have
On 2013-01-15 14:40:11 -0500, Tom Lane wrote:
Sergey Koposov kopo...@ast.cam.ac.uk writes:
And I do see the tblspc file left after the finish of make check:
tmp_check/data/pg_tblspc/16385/PG_9.3_201212081/16384/16387
Interesting. If the tests are run immediately after initdb, 16387
Andres Freund and...@2ndquadrant.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;
On 2013-01-15 17:56:40 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.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
On 2013-01-16 00:26:01 +0100, Andres Freund wrote:
On 2013-01-15 17:56:40 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.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
Andres Freund and...@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?
On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
Andres Freund and...@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
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
At this point I'm more interested in his report in
alpine.lrh.2.03.1301152012220@ast.cam.ac.uk about
the Assert at spgdoinsert.c:1222 failing. That's pretty new code, so
more likely to have a
On 2013-01-16 02:13:26 +0100, Andres Freund wrote:
On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
Andres Freund and...@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)).
[
On 2013-01-15 20:32:00 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
At this point I'm more interested in his report in
alpine.lrh.2.03.1301152012220@ast.cam.ac.uk about
the Assert at spgdoinsert.c:1222 failing.
On 2013-01-16 02:34:52 +0100, Andres Freund wrote:
On 2013-01-16 02:13:26 +0100, Andres Freund wrote:
On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
FWIW its also triggerable if two other function calls are places inside
the above if() (I
Andres Freund and...@2ndquadrant.com writes:
-O0 passes
Grumble... suspect we're chasing another compiler bug now, but ...
You might try -O1; if that shows the bug it'll probably be a tad easier
to debug in.
regards, tom lane
--
Sent via pgsql-hackers mailing list
It's a compiler bug.
icc 11.1 apparently thinks that this loop in doPickSplit:
/*
* Update nodes[] array to point into the newly formed innerTuple, so that
* we can adjust their downlinks below.
*/
SGITITERATE(innerTuple, i, node)
{
nodes[i] = node;
}
is
23 matches
Mail list logo
