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

Re: Sync Rep Design

From: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sync Rep Design
Date: 2010-12-31 07:50:07
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On 30.12.2010 22:27, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs<simon(at)2ndquadrant(dot)com>  wrote:
>> synchronous_replication (boolean)
>>         Specifies whether transaction commit will wait for WAL records
>>         to be replicated before the command returns a "success"
>>         indication to the client.
> The word "replicated" here could be taken to mean different things,
> most obviously:
> - slave has received the WAL
> - slave has fsync'd the WAL
> - slave has applied the WAL
Perhaps the level of "replication guarantee" should be decided on the 
slave side, by
having a configuration parameter there

report_as_replicated = received|written_to_disk|fsynced|applied

for different types of hosts may have wildly different guarantees and 
parameters for these. One could envision a WAL-archive type "standby" 
which is
there for data persistence only will and never "apply" WAL.

of couse we could put a bitmap in the status update messages from slave 
and have
some quorum on options on master for when the data is "in sync", say 
"need 5 received
or (1 applied and 1 fsynced)", but I am pretty sure that trying to get 
anywhere with this
before applying the basic sync rep patch would push back sync rep to at 
least 9.2 if not 9.5

Hannu Krosing

In response to


pgsql-hackers by date

Next:From: Hannu KrosingDate: 2010-12-31 07:50:43
Subject: Re: Sync Rep Design
Previous:From: Noah MischDate: 2010-12-31 05:47:46
Subject: Re: Avoiding rewrite in ALTER TABLE ALTER TYPE

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