Re: Win32 Powerfail testing - Mailing list pgsql-hackers

From Dave Page
Subject Re: Win32 Powerfail testing
Date
Msg-id 03AF4E498C591348A42FC93DEA9661B885CA@mail.vale-housing.co.uk
Whole thread Raw
In response to Win32 Powerfail testing  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers

> -----Original Message-----
> From: Kevin Brown [mailto:kevin@sysexperts.com]
> Sent: 06 March 2003 04:37
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Win32 Powerfail testing
>
>
> Tatsuo Ishii wrote:
> > Sorry, but it does not help. The page says we could use
> > FlushFileBuffers() to sync the kernel buffer to the
> > disk. Unfortunately, it requires a file descriptor to flush for its
> > argument. Thus it could not be a replacement of sync(). Actually I
> > have modified the buffer manager so that it remembers all file
> > descriptors those have not been synced yet to the disk at the
> > checkpoint time to sync them later. However I found this
> modification
> > does not help at all with some reason I don't know.
>
> It would be an interesting comparison for you to roll the
> file descriptor tracking changes into the Unix side of the
> tree and use
> fsync() or fdatasync() in place of FlushFileBuffers() on the
> Unix side (you'd have to remove or disable the code that does
> a sync() of course).  If the end result yields no data
> corruption issues during powerfail testing on various Unix
> platforms then it's reasonably likely that the problem you're
> experiencing on the Windows side is with the underlying
> Windows platform and not with your code.

Agreed, but I still keep thinking that despite some peoples claims that
Windows ain't up to it, DB2, SQL and Exchange Server as well a probably
others that don't use raw partitions have got over this problem, so
therefore we should be able to. Admittedly Microsoft have a bit of an
advantage over us, but there must be some accessible way of flushing the
buffers in a guaranteed way. I'll look into it some more today if I
can...

Regards, Dave.


pgsql-hackers by date:

Previous
From: Christoph Haller
Date:
Subject: Re: Error codes revisited
Next
From: Mike Mascari
Date:
Subject: Re: Error codes revisited