Re: Curious buildfarm failures - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Curious buildfarm failures
Date
Msg-id 20130115160425.GK5115@awork2.anarazel.de
Whole thread Raw
In response to Re: Curious buildfarm failures  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Curious buildfarm failures
Re: Curious buildfarm failures
List pgsql-hackers
On 2013-01-14 22:56:47 +0100, Andres Freund wrote:
> On 2013-01-14 22:50:16 +0100, Andres Freund wrote:
> > On 2013-01-14 16:35:48 -0500, Tom Lane wrote:
> > > Since commit 2065dd2834e832eb820f1fbcd16746d6af1f6037, there have been
> > > a few buildfarm failures along the lines of
> > >
> > >   -- Commit table drop
> > >   COMMIT PREPARED 'regress-two';
> > > ! PANIC:  failed to re-find shared proclock object
> > > ! PANIC:  failed to re-find shared proclock object
> > > ! connection to server was lost
> > >
> > > Evidently I bollixed something, but what?  I've been unable to reproduce
> > > this locally so far.  Anybody see what's wrong?
> > >
> > > Another thing is that dugong has been reproducibly failing with
> > >
> > >  drop cascades to table testschema.atable
> > >   -- Should succeed
> > >   DROP TABLESPACE testspace;
> > > + ERROR:  tablespace "testspace" is not empty
> > >
> > > since the elog-doesn't-return patch (b853eb97) went in.  Maybe this is
> > > some local problem there but I'm suspicious that there's a connection.
> > > But what?
> > >
> > > Any insights out there?
> >
> > It also has:
> >
> > FATAL:  could not open file "base/16384/28182": No such file or directory
> > CONTEXT:  writing block 6 of relation base/16384/28182
> > TRAP: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1743)
> 
> > #3  0x4000000000b4b510 in ExceptionalCondition (
> >     conditionName=0x4000000000d76390 "!(PrivateRefCount[i] == 0)",
> >     errorType=0x4000000000d06500 "FailedAssertion",
> >     fileName=0x4000000000d76260 "bufmgr.c", lineNumber=1743) at assert.c:54
> > #4  0x40000000007a7d20 in AtProcExit_Buffers (code=1, arg=59) at bufmgr.c:1743
> > #5  0x40000000007c4e50 in shmem_exit (code=1) at ipc.c:221
> >
> > in the log. So it seems like it also could be related to locking
> > changes although I don't immediately see why.
> 
> No such "luck" though, the animal only applied the elog commits:
> http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=dugong&dt=2013-01-14%2000%3A00%3A02&stg=SCM-checkout

Do you have idea whats going on? I don't really have any clue other than
guessing it might be an compiler bug.

Could the buildfarm owner perhaps tell us which files are left in the
tablespace 'testspace'?

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT
Next
From: Tom Lane
Date:
Subject: Re: pg_ctl idempotent option