Re: Changing the default wal_sync_method to open_sync for
От | Marc G. Fournier |
---|---|
Тема | Re: Changing the default wal_sync_method to open_sync for |
Дата | |
Msg-id | 20050317141328.Q954@ganymede.hub.org обсуждение исходный текст |
Ответ на | Re: Changing the default wal_sync_method to open_sync for (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Changing the default wal_sync_method to open_sync for
Re: Changing the default wal_sync_method to open_sync for |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: