Re: Idea for fixing the Windows fsync problem - Mailing list pgsql-hackers

From Takayuki Tsunakawa
Subject Re: Idea for fixing the Windows fsync problem
Date
Msg-id 011e01c739da$a5e8ce20$19527c0a@OPERAO
Whole thread Raw
In response to Idea for fixing the Windows fsync problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Idea for fixing the Windows fsync problem
List pgsql-hackers
From: "Tom Lane" <tgl@sss.pgh.pa.us>I suggested that here
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00642.php
> but have received no feedback about it ...

I'm sorry, I missed it.

From: "Tom Lane" <tgl@sss.pgh.pa.us>
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> So: maybe the solution is to add a step to the drop sequence,
namely
>>> revoking any pending fsync request, before unlink.
>
>> Perhaps we could have the bgwrite check the queue *if* it gets the
>> ENOENT/EACCESS error and then re-check the queue for drops on that
file?
>
> I've committed a tentative patch along these lines to HEAD.  Please
> test.

I agree with Magnus-san's suggestion, too.
Though I'm willing to test, I'm not familiar with building on Windows
yet and do not have enogh time for other works right now.  If someone
builds and gives me the new postgres.exe, I'll put it on my 8.2
installation and test.  Or, could anyone do the following?  These are
what I did in yesterday's test.

1. Open two psql sessions.  Let me call those session1  and session2.

2. On session1, execute:

create table a (c int);
insert into a values(1);

3. On session2, execute:

select * from a;

4. On session1, execute:

drop table a;
checkpoint;

Checkpoint command here reported an error yesterday.  If Tom-san's
patch is effective, it should not fail and no messages are put in the
event log.





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Idea for fixing the Windows fsync problem
Next
From: "Takayuki Tsunakawa"
Date:
Subject: What is the motivation of include directive and configuration files outside PGDATA