Re: race condition for drop schema cascade?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: race condition for drop schema cascade?
Дата
Msg-id 11170.1104341216@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: race condition for drop schema cascade?  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: race condition for drop schema cascade?
Re: race condition for drop schema cascade?
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: buildfarm NetBSD/m68k tsearch regression failure
Следующее
От: Bruce Momjian
Дата:
Сообщение: RC3 on Friday