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
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 |