* Win32, with fsync, write-cache disabled: no data corruption
* Win32, with fsync, write-cache enabled: no data corruption
* Win32, with osync, write cache disabled: no data corruption
* Win32, with osync, write cache enabled: no data
corruption. Once
I
got:
Magnus Hagander wrote:
This indicated to me that open_sync did not require any
additional changes than our current fsync.
fsync and open_sync both write through the write cache in the operating
system. Only fsync=off turns this off.
fsync also writes through the hardware write cache.
Bruce Momjian pgman@candle.pha.pa.us writes:
However, I do prefer this patch and let Win32 have the same write cache
issues as Unix, for consistency.
I agree that the open flag is more nearly O_DSYNC than O_SYNC.
ISTM Windows' idea of fsync is quite different from Unix's and therefore
we
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
However, I do prefer this patch and let Win32 have the same write cache
issues as Unix, for consistency.
I agree that the open flag is more nearly O_DSYNC than O_SYNC.
ISTM Windows' idea of fsync is quite different from Unix's
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
we should name the wal_sync_method that invokes it something different
than fsync. write_through or some such? We already have precedent
that not all wal_sync_method values are available on all platforms.
Yes, I am thinking that
, 2005 10:53 AM
To: Tom Lane
Cc: Magnus Hagander; Michael Paesold; pgsql-hackers@postgresql.org;
[EMAIL PROTECTED]; Merlin Moncure
Subject: Re: [pgsql-hackers-win32] [HACKERS] win32 performance - fsync
question
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
However, I do prefer
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
ISTM Windows' idea of fsync is quite different from Unix's and therefore
we should name the wal_sync_method that invokes it something different
than fsync. write_through or some such?
Ah, I remember now. On
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
ISTM Windows' idea of fsync is quite different from Unix's and therefore
we should name the wal_sync_method that invokes it something different
than fsync. write_through or some such?
Ah, I remember now. On Win32 our fsync is:
Michael Paesold wrote:
Magnus Hagander wrote:
Magnus Hagander wrote:
Magnus prepared a trivial patch which added the O_SYNC flag
for windows and mapped it to FILE_FLAG_WRITE_THROUGH in
win32_open.c.
[snip]
Michael Paesold wrote:
The original patch did not have any
Bruce Momjian wrote:
Michael Paesold wrote:
Magnus Hagander wrote:
[snip]
Michael, I am not sure why you come to the conclusion that open_sync
requires turning off the disk write cache. I saw nothing to indicate
that in the thread:
I was just seeing his error message below...
-Original Message-
From: [EMAIL PROTECTED] on behalf of Bruce Momjian
Sent: Sun 2/27/2005 12:54 AM
To: Magnus Hagander
Cc: Tom Lane; pgsql-hackers@postgresql.org; [EMAIL PROTECTED]; Merlin Moncure
Subject: Re: [pgsql-hackers-win32] [HACKERS] win32 performance - fsync question
Patch
Moncure
Subject: Re: [pgsql-hackers-win32] [HACKERS] win32 performance
- fsync question
Patch applied. Thanks.
I assume this is not approprate for 8.0.X.
---
Magnus Hagander wrote:
Magnus prepared a trivial patch which
Are you verifying that all the data that was committed was actually stored?
Or
just verifying that the database works properly after rebooting?
I verified the data.
Does pg startup increase the xid by some amount (say 1000 xids) after crash ?
Else I think you would also need to rollback a
Magnus prepared a trivial patch which added the O_SYNC flag for
windows and mapped it to FILE_FLAG_WRITE_THROUGH in win32_open.c.
Attached is this trivial patch. As Merlin says, it needs some
more reliability testing. But the numbers are at least reasonable - it
*seems* like it's doing
In the final test, the BIOS decided the disk was giving up and
reassigned it as 0Mb.. Required two extra cold boots, then it was back
up to 20Gb. Still no data loss.
I think it would be fun to re-run these tests with MySQL...
Chris
---(end of
My results are:
Fisrt, baseline:
* Linux, with fsync (default), write-cache disabled: no data corruption
* Linux, with fsync (default), write-cache enabled: usually no data
corruption, but two runs which had
* Win32, with fsync, write-cache disabled: no data corruption
* Win32, with fsync,
Magnus Hagander [EMAIL PROTECTED] writes:
My results are:
Fisrt, baseline:
* Linux, with fsync (default), write-cache disabled: no data corruption
* Linux, with fsync (default), write-cache enabled: usually no data
corruption, but two runs which had
That makes sense.
* Win32, with fsync,
* Win32, with fsync, write-cache disabled: no data corruption
* Win32, with fsync, write-cache enabled: no data corruption
* Win32, with osync, write cache disabled: no data corruption
* Win32, with osync, write cache enabled: no data corruption. Once I
got:
2005-02-24 12:19:54 LOG:
Magnus Hagander [EMAIL PROTECTED] writes:
* Linux, with fsync (default), write-cache enabled: usually no data
corruption, but two runs which had
Are you verifying that all the data that was committed was actually stored? Or
just verifying that the database works properly after rebooting?
I'm
Greg Stark [EMAIL PROTECTED] writes:
I'm a bit surprised that the write-cache lead to a corrupt database, and not
merely lost transactions. I had the impression that drives still handled the
writes in the order received.
There'd be little point in having a cache if they did, I should think.
I
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
I'm a bit surprised that the write-cache lead to a corrupt database, and not
merely lost transactions. I had the impression that drives still handled the
writes in the order received.
There'd be little point in
You may find that if you check this case again that the
usually no data
corruption is actually usually lost transactions but no
corruption.
That's a good point, but it seems difficult to be sure of the last
reportedly-committed transaction in a powerfail situation. Maybe if
you drive the
* Linux, with fsync (default), write-cache enabled: usually no data
corruption, but two runs which had
Are you verifying that all the data that was committed was
actually stored? Or
just verifying that the database works properly after rebooting?
I verified the data.
I'm a bit surprised
Magnus Hagander [EMAIL PROTECTED] writes:
I'm a bit surprised that the write-cache lead to a corrupt database, and
not merely lost transactions. I had the impression that drives still
handled the writes in the order received.
In this case, it was lost transactions, not data corruption.
Magnus prepared a trivial patch which added the O_SYNC flag
for windows and mapped it to FILE_FLAG_WRITE_THROUGH in
win32_open.c.
Attached is this trivial patch. As Merlin says, it needs some more
reliability testing. But the numbers are at least reasonable - it
*seems* like it's doing the
25 matches
Mail list logo
