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: 423A3621.9030506@familyhealth.com.au (view raw or flat)
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?

Chris

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-2014 The PostgreSQL Global Development Group