Skip site navigation (1) Skip section navigation (2)

Re: Curious buildfarm failures (fwd)

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk>, pgsql-hackers(at)postgreSQL(dot)org,Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: Curious buildfarm failures (fwd)
Date: 2013-01-15 22:30:22
Message-ID: 20130115223022.GB3089@awork2.anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On 2013-01-15 14:40:11 -0500, Tom Lane wrote:
> Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)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 tablespace regression
> test.  But why would only that table be left behind?  There are half
> a dozen relations in that tablespace at the point of the DROP CASCADE.
> 
> 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 a similar ICC version (dugong's says it is 10.0 20070809)
> to try?  Also, Sergey, can you find a non-dot-zero release to try?

I played a bit arround (thanks Sergey!) and it seems to be some rather
strange optimization issue around the fsync request queue.

Namely changing 

	/* OK, insert request */
	request = &CheckpointerShmem->requests[CheckpointerShmem->num_requests++];
	request->rnode = rnode;
	request->forknum = forknum;
	request->segno = segno;
into
	/* OK, insert request */
	request = &CheckpointerShmem->requests[CheckpointerShmem->num_requests++];
	request->rnode.spcNode = rnode.spcNode;
	request->rnode.dbNode = rnode.dbNode;
	request->rnode.relNode = rnode.relNode;
	request->forknum = forknum;
	request->segno = segno;
makes it pass reliably.

Displaying the values of request after the assignment, but without the
change shows bogus values showing up which explains the problems.

How the hell thats correlating with the elog changes I don't yet know.

Greetings,

Andres Freund

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


In response to

Responses

pgsql-hackers by date

Next:From: Stephen FrostDate: 2013-01-15 22:33:16
Subject: Re: Parallel query execution
Previous:From: Kohei KaiGaiDate: 2013-01-15 22:28:40
Subject: Re: Review of Row Level Security

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group