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

Reply via email to