Re: Curious buildfarm failures

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Curious buildfarm failures
Дата
Msg-id 20130115160425.GK5115@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Curious buildfarm failures  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Curious buildfarm failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Curious buildfarm failures  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_ctl idempotent option