Re: Idea for fixing the Windows fsync problem
От | Tom Lane |
---|---|
Тема | Re: Idea for fixing the Windows fsync problem |
Дата | |
Msg-id | 3686.1169004250@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Idea for fixing the Windows fsync problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
I wrote: > I've committed a tentative patch along these lines to HEAD. Please > test. So I come home from dinner out, and find the buildfarm all red :-( I'm not sure why I didn't see this failure in my own testing, but in hindsight it's quite obvious that if the bgwriter is to take a hard line about fsync failures, it's got to be told about DROP DATABASE not only DROP TABLE --- that is, there has to be a signaling message for "revoke fsync requests across whole database". I think that it should not be necessary to invent a signal for "drop across tablespace", though, because we don't allow DROP TABLESPACE to remove any tables --- you've got to drop tables and/or databases to clean out the tablespace, first. Anyone see a flaw in that? Not up to fixing this right now, but will have a go at it in the morning, unless someone else wants to take a swing at it meanwhile. BTW: what happens on Windows if we're trying to do the equivalent of "rm -rf database-dir" and someone is holding open one of the files in the directory? Or has the directory itself open for readdir()? regards, tom lane
В списке pgsql-hackers по дате отправления: