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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-hackers-win32 by date

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