From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Idea for fixing the Windows fsync problem |
Date: | 2007-01-17 03:24:10 |
Message-ID: | 3686.1169004250@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-01-17 03:47:15 | Re: What is the motivation of include directive and |
Previous Message | Bruce Momjian | 2007-01-17 03:02:34 | Re: Temparary disable constraint |