Re: race condition for drop schema cascade?

Tom,

my systems are all EXT3 (Debian 3.1) (andrew can tell you which ones they are).

Jim

---------- Original Message -----------
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Kurt Roeckx <Q(at)ping(dot)be>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Sent: Wed, 29 Dec 2004 12:26:56 -0500
Subject: Re: [HACKERS] 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
------- End of Original Message -------