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> |
Subject: | Re: race condition for drop schema cascade? |
Date: | 2004-12-29 17:26:56 |
Message-ID: | 11170.1104341216@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-12-29 17:28:34 | RC3 on Friday |
Previous Message | Tom Lane | 2004-12-29 17:05:16 | Re: buildfarm NetBSD/m68k tsearch regression failure |