Re: race condition for drop schema cascade?

Andrew Dunstan <andrew(at)dunslane(dot)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