On 2013-01-15 11:19:28 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> >>> On 2013-01-14 16:35:48 -0500, Tom Lane wrote:
> >>>> 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?
>
> > Do you have idea whats going on? I don't really have any clue other than
> > guessing it might be an compiler bug.
>
> I'm suspicious of that too, but it's hard to see why it would manifest
> like this while everything else appears to be fine. A codegen bug
> triggered by elog ought to show up in a lot of places, one would think.
The make output showed that for some files optimization were disabled by
the compiler because they were to complex. Its possible that it is
related to that :(.
Interestingly the compiler couldn't deduce that
e.g. DateTimeParseError() didn't return with the old ereport definition
but it can with the new one which seems strange.
> > Could the buildfarm owner perhaps tell us which files are left in the
> > tablespace 'testspace'?
>
> I'm betting the answer is "none", and that what's happening is some sort
> of timing problem (ie, the DROP TABLESPACE somehow isn't waiting for the
> checkpointer process to clean out all the just-dropped files). The
> PANIC at shutdown looks like it might be some sort of doppelganger of
> the same bug, ie dropped table cleaned out too early.
It seems strange tho that it started failing exactly with that commit
and all runs failed exactly the same way since.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services