Re: limiting performance impact of wal archiving.

Laurent Laborde wrote:
> On Tue, Nov 10, 2009 at 5:35 PM, Greg Smith <greg@2ndquadrant.com> wrote:
>
> I have 1 spare dedicated to hot standby, doing nothing but waiting for
> the master to fail.
> + 2 spare candidate for cluster mastering.
>
> In theory, i could even disable fsync and all "safety" feature on the master.
>
There are two types of safety issues here:

1) Will the database be corrupted if there's a crash?  This can happen
if you turn off fsync, and you'll need to switch to a standby to easily
get back up again

2) Will you lose transactions that have been reported as committed to a
client if there's a crash?  This you're exposed to if synchronous_commit
is off, and whether you have a standby or not doesn't change that fact.

> Everybody told me "nooo ! LVM is ok, no perceptible overhead, etc ...)
> Are you 100% about LVM ? I'll happily trash it :)
Believing what people told you is how you got into trouble in the first
place.  You shouldn't believe me either--benchmark yourself and then
you'll know.  As a rule, any time someone suggests there's a
technological approach that makes it easier to manage disks, that
approach will also slow performance.  LVM vs. straight volumes, SAN vs.
direct-attached storage, VM vs. real hardware, it's always the same story.

--
Greg Smith    greg@2ndQuadrant.com    Baltimore, MD