Thread: Re: Changing the default wal_sync_method to open_sync for Win32?
> >> I'd like to see this one also considered for 8.0.x, though I'd > >> certainly like to see some more testing as well. Perhaps it's > >> suitable for the "8.0.x with extended testing" that is planned for > >> the ARC replacement code? > >> > >> It does make a huge difference on win32. While we definitly don't > >> want to risk data, a 60% speedup in write intensive apps > is a *lot*. > > > > Notice we never default to open_sync. However, on Win32, > Magnus got a > > 60% speedup by using open_sync, implemented using > > FILE_FLAG_WRITE_THROUGH. Now, because this the fastest on Win32, I > > think we should default to open_sync on Win32. The attached patch > > implements this. > > Considering how stable an Operating System Windows *isn't*, I The difference has nothing to do with the stability of the OS. It has to do with wether we ignore the *hardware* write cache or not. Both methods ignore the OS write cache. > think the first thing Magnus states very much goes against > making this the default: > "While we definitely don't want to risk data..." ... > > Setting something like this that increases the risk to data > should never be 'the default behaviour', but a conscious > decision on the part of the administrator of the individual > system ... and even then, with a good skull-n-cross bones > warning around it so that they understand the risks ... The same level of "risk due to write cache" exists on all other operating systems already. (Actually, I only know it exists on linux, but it sure looks like it exists on most others looking at performance figures) //Magnus
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian > Sent: 17 March 2005 04:20 > To: Magnus Hagander > Cc: Tom Lane; pgsql-hackers@postgresql.org; > pgsql-hackers-win32@postgresql.org; Merlin Moncure > Subject: [HACKERS] Changing the default wal_sync_method to > open_sync for Win32? > > 1. Should it be the default wal_sync_method for Win32? Yes. > 2. Another question is what to do with 8.0.X? Do we > backpatch this for > Win32 performance? Can we test it enough to know it will work well? > 8.0.2 is going to have a more rigorous testing cycle because of the > buffer manager changes. This question was asked earlier, and iirc, a few people said yes, and no-one said no. I'm most definitely in the yes camp. Regards, Dave.
Dave Page wrote: > > 2. Another question is what to do with 8.0.X? Do we > > backpatch this for > > Win32 performance? Can we test it enough to know it will work well? > > 8.0.2 is going to have a more rigorous testing cycle because of the > > buffer manager changes. > > This question was asked earlier, and iirc, a few people said yes, and > no-one said no. I'm most definitely in the yes camp. I have backpatched O_SYNC for Win32 to 8.0.X. Everyone seems to agree it should be supported by wal_sync_method. --- the "default" issue still needs discussion. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Thu, 17 Mar 2005, Bruce Momjian wrote: > Dave Page wrote: >>> 2. Another question is what to do with 8.0.X? Do we >>> backpatch this for >>> Win32 performance? Can we test it enough to know it will work well? >>> 8.0.2 is going to have a more rigorous testing cycle because of the >>> buffer manager changes. >> >> This question was asked earlier, and iirc, a few people said yes, and >> no-one said no. I'm most definitely in the yes camp. > > I have backpatched O_SYNC for Win32 to 8.0.X. Everyone seems to agree > it should be supported by wal_sync_method. --- the "default" issue > still needs discussion. Even with Magnus' explanation that we're talking Hardware, and not OS risk issues, I still think that the default should be the "least risky", with the other options being well explained from both a risk/performance standpoint, so that its a conscious decision on the admin's side ... Any 'risk of data loss' has always been taboo, making the default behaviour be to increase that risk seems to be a step backwards to me .. having the option, fine ... effectively forcing that option is what I'm against (and, by forcing, I mean how many ppl "change from the default"?) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Thu, 17 Mar 2005, Bruce Momjian wrote: > > > Dave Page wrote: > >>> 2. Another question is what to do with 8.0.X? Do we > >>> backpatch this for > >>> Win32 performance? Can we test it enough to know it will work well? > >>> 8.0.2 is going to have a more rigorous testing cycle because of the > >>> buffer manager changes. > >> > >> This question was asked earlier, and iirc, a few people said yes, and > >> no-one said no. I'm most definitely in the yes camp. > > > > I have backpatched O_SYNC for Win32 to 8.0.X. Everyone seems to agree > > it should be supported by wal_sync_method. --- the "default" issue > > still needs discussion. > > Even with Magnus' explanation that we're talking Hardware, and not OS risk > issues, I still think that the default should be the "least risky", with > the other options being well explained from both a risk/performance > standpoint, so that its a conscious decision on the admin's side ... > > Any 'risk of data loss' has always been taboo, making the default > behaviour be to increase that risk seems to be a step backwards to me .. > having the option, fine ... effectively forcing that option is what I'm > against (and, by forcing, I mean how many ppl "change from the default"?) I understand that logic. Please see my posting that their fsync is something we don't have on Unix. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> Even with Magnus' explanation that we're talking Hardware, and not OS > risk issues, I still think that the default should be the "least risky", > with the other options being well explained from both a risk/performance > standpoint, so that its a conscious decision on the admin's side ... > > Any 'risk of data loss' has always been taboo, making the default > behaviour be to increase that risk seems to be a step backwards to me .. > having the option, fine ... effectively forcing that option is what I'm > against (and, by forcing, I mean how many ppl "change from the default"?) But doesn't making it the default just make it identical to the default freebsd configuration? ie. Identical risk? Chris