Re: write ahead logging in standby (streaming replication)

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: write ahead logging in standby (streaming replication)
Date: 2009-11-12 16:49:18
Message-ID: 4AFC3C8E.1070505@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
>
>> The problem is that fsync needs to be issued too frequently, which would
>> be harmless in asynchronous replication, but not in synchronous one.
>> A transaction would have to wait for the primary's and standby's fsync
>> before returning a "success" to a client.
>>
>
> Surely that is exactly what is *required* if the user has asked for
> synchronous replication.
>
This a distressingly common thing people get wrong about replication.
You can either have synchronous replication, which as you say has to be
slow: you must wait for an fsync ACK from the secondary and a return
trip before you can say something is committed on the primary. Or you
can get better performance by not waiting for all of those things, but
the minute you do that it's *not* synchronous replication anymore. You
can't get high-performance and true synchronous behavior; you have to
pick one. The best you can do if you need both is work on accelerating
fsync everywhere using the standard battery-backed write cache technique.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2009-11-12 17:45:24 CommitFest 2009-11 Call for Reviewers
Previous Message Andrew Chernow 2009-11-12 16:47:30 Re: Listen / Notify rewrite