Re: race condition for drop schema cascade? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: race condition for drop schema cascade?
Date
Msg-id 11170.1104341216@sss.pgh.pa.us
Whole thread Raw
In response to Re: race condition for drop schema cascade?  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: race condition for drop schema cascade?
Re: race condition for drop schema cascade?
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> You're right - my query was not sufficiently specific. There have in 
> fact been 4 failures:

> pgbuildfarm=# select sysname, snapshot, stage, branch from build_status 
> where log ~ 'tablespace "testspace" is not empty.*tablespace "testspace" 
> is not empty' and not log ~ 'No space left';
>  sysname |      snapshot       |    stage     | branch
>  --------+---------------------+--------------+--------
>  hare    | 2004-12-09 05:15:05 | Check        | HEAD
>  otter   | 2004-12-11 15:50:09 | Check        | HEAD
>  otter   | 2004-12-15 15:50:10 | Check        | HEAD
>  gibbon  | 2004-12-28 23:55:05 | InstallCheck | HEAD

Why does the last show as an "install" failure?

Anyway, given the small number of machines involved, I'm once again
wondering what filesystem they are using.  They wouldn't be running
the check over NFS, by any chance, for instance?

The theory that is in my mind is that the bgwriter could have written
out a page for the table in the test tablespace, and thereby be holding
an open file pointer for it.  On standard Unix filesystems this would
not disrupt the backend's ability to unlink the table at the DROP stage,
but I'm wondering about nonstandard filesystems ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: buildfarm NetBSD/m68k tsearch regression failure
Next
From: Bruce Momjian
Date:
Subject: RC3 on Friday