Bruce Momjian 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:
> #define
Tom Lane wrote:
> Bruce Momjian 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
, 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 writes:
> > However, I do prefer this patch and
Bruce Momjian 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 too. I hesis
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 should name the wal_sync_m
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
> > > > * 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
>
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...
http://archives.postg
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 d
-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
> Pa
e; pgsql-hackers@postgresql.org;
>[EMAIL PROTECTED]; Merlin Moncure
>Subject: Re: [pgsql-hackers-win32] [HACKERS] win32 performance
>- fsync question
>
>
>
>Patch applied. Thanks.
>
>I assume this is not approprate for 8.0.X.
>
>-
> >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 rol
"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 c
>> * 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 surpr
>> 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
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
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
"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?
> "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, 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
"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
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, write-ca
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 broadcast)--
> > 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
>> 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 d
26 matches
Mail list logo
