From: "Tom Lane" <tgl@sss.pgh.pa.us>
>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".
>
Excuse me if I misunderstand English and say something strange.
I thought "buildfarm is red" meant the failure of regression test.
What kind of errors did you get in what operation (e.g. DROP INDEX)?
Is everyone is able to see the test result freely? Sorry, I'll read
developer's FAQ when I have more time.
And I thought you meant you have a question: why doesn't bgwriter
report "checkpoint request failed" when a checkpoint occurs after
dropping a database?
No, checkpoint after DROP DATABASE should not report "checkpoint
request failed." When dropping a database, checkpoint is forced
before removing the database files, so bgwriter does not try to open
for fsync the database files. I saw this in the following code
fragment in src/backend/commands/dbcommands.c:
----------------------------------------/* * On Windows, force a checkpoint so that the bgwriter doesn't hold
any * open files, which would cause rmdir() to fail. */
#ifdef WIN32RequestCheckpoint(true, false);
#endif
/* * Remove all tablespace subdirs belonging to the database. */remove_dbtablespaces(db_id);
----------------------------------------
> 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?
I think you are right.
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()?
And I wonder what happens if Windows "copy" command is accessing the
data files when bgwriter tries to open them for fsync, or the reverse
of it. copy would fail? If so, it means that online backup sometimes
fails.
And how about a checkpoint after ALTER TABLE/INDEX ... SET TABLESPACE?
When bgwriter tries to open the table/index file, the original file
does not exist.
