From: "Tom Lane" <[EMAIL PROTECTED]> >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 WIN32 RequestCheckpoint(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. ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org