Tom,
my systems are all EXT3 (Debian 3.1) (andrew can tell you which ones they are).
Jim
---------- Original Message -----------
From: Tom Lane <[EMAIL PROTECTED]>
To: Andrew Dunstan <[EMAIL PROTECTED]>
Cc: Kurt Roeckx <[EMAIL PROTECTED]>, PostgreSQL-development
<pgsql-hackers@postgresql.org>
Sent: Wed, 29 Dec 2004 12:26:56 -0500
Subject: Re: [HACKERS] race condition for drop schema cascade?
> Andrew Dunstan <[EMAIL PROTECTED]> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
------- End of Original Message -------
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
