Re: Idea for fixing the Windows fsync problem

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

In response to

Responses

Browse pgsql-hackers by date

  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