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

Re: Sync Rep Design

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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 10:06:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 31.12.2010 09:50, Hannu Krosing wrote:
> 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
> performance
> parameters for these. One could envision a WAL-archive type "standby"
> which is
> there for data persistence only will and never "apply" WAL.

Agreed, it feels natural to specify when a piece of WAL is acknowledged 
in the standby.

Regarding the rest of the proposal, I would still prefer the UI 
discussed here:

It ought to be the same amount of work to implement, and provides the 
same feature set, but makes administration a bit easier by being able to 
name the standbys. Also, I dislike the idea of having the standby 
specify that it's a synchronous standby that the master has to wait for. 
Behavior on the master should be configured on the master.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-12-31 10:26:11
Subject: Re: Sync Rep Design
Previous:From: Magnus HaganderDate: 2010-12-31 09:58:34
Subject: Re: Old git repo

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