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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
