Re: Curious buildfarm failures

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, math(at)sai(dot)msu(dot)ru
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Curious buildfarm failures
Date: 2013-01-15 16:04:25
Message-ID: 20130115160425.GK5115@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-15 16:06:44 Re: pg_ctl idempotent option
Previous Message Tom Lane 2013-01-15 15:57:54 Re: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT