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

Re: Sync Rep Design

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sync Rep Design
Date: 2010-12-30 20:11:40
Message-ID: AANLkTikcji+2VuE95y0rgwD3bTjK5wSLAJuPwRUFfE81@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Most of your doc uses the terms "primary" and "standby", but a few
instances of "master" and "slave" have slipped in. I think it's better
to stick to consistent terminology.

On Thu, Dec 30, 2010 at 21:04, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> With synchronous replication options specified at the application level
> (on the master) we can offer sync rep for the most important changes,
> without slowing down the bulk of the total workload. Application level
> options are an important and practical tool for allowing the benefits of
> synchronous replication for high performance applications. This feature
> is unique to PostgreSQL.

I think a comment about the "head-of-line blocking" nature of
streaming repliaction is in order. If you execute massive writes in
async mode and then run a transaction in sync mode, its commit will be
delayed until all the async transactions before it have been applied
on the slave.

> synchronous_replication_timeout (boolean)

Doesn't look like a boolean to me :)

Regards,
Marti

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-12-30 20:23:18
Subject: Re: estimating # of distinct values
Previous:From: Robert TreatDate: 2010-12-30 20:07:16
Subject: Re: Sync Rep Design

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