Skip site navigation (1) Skip section navigation (2)

Re: Changing the default wal_sync_method to open_sync for

From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Dave Page <dpage(at)vale-housing(dot)co(dot)uk>,Magnus Hagander <mha(at)sollentuna(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,pgsql-hackers(at)postgresql(dot)org, pgsql-hackers-win32(at)postgresql(dot)org,Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Subject: Re: Changing the default wal_sync_method to open_sync for
Date: 2005-03-18 02:00:01
Message-ID: (view raw or whole thread)
Lists: pgsql-hackerspgsql-hackers-win32
> 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?


In response to

pgsql-hackers by date

Next:From: Christopher BrowneDate: 2005-03-18 03:28:47
Subject: Re: Excessive growth of pg_attribute and other system tables
Previous:From: Greg StarkDate: 2005-03-18 01:57:52
Subject: Re: Lockfile restart failure is still there :-(

pgsql-hackers-win32 by date

Next:From: Bruce MomjianDate: 2005-03-20 05:11:18
Subject: Re: [pgsql-hackers-win32] snprintf causes regression tests
Previous:From: Bruce MomjianDate: 2005-03-17 19:38:32
Subject: Re: [pgsql-hackers-win32] win32 performance - fsync question

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group