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@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Kurt Roeckx <Q@ping.be>, 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 <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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
------- End of Original Message -------