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

Re: Synchronous replication - patch status inquiry

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, fazool mein <fazoolmein(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Synchronous replication - patch status inquiry
Date: 2010-09-03 03:50:50
Message-ID: AANLkTikA9jPK4JqyFQFPRwZThhsu3v4+sWEyidUJmTXG@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Sep 2, 2010 at 11:32 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> I understand what you're after, the idea of being able to set
> synchronization level on a per-transaction basis is cool. But I haven't seen
> a satisfactory design for it. I don't understand how it would work in
> practice. Even though it's cool, having different kinds of standbys
> connected is a more common scenario, and the design needs to accommodate
> that too. I'm all ears if you can sketch a design that can do that.

That design would affect what the standby should reply. If we choose
async/recv/fsync/replay on a per-transaction basis, the standby
should send multiple LSNs and the master needs to decide when
replication has been completed. OTOH, if we choose just sync/async,
the standby has only to send one LSN.

The former seems to be more useful, but triples the number of ACK
from the standby. I'm not sure whether its overhead is ignorable,
especially when the distance between the master and the standby is
very long.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-09-03 04:19:17
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Previous:From: Michael HaggertyDate: 2010-09-03 03:17:15
Subject: Re: git: uh-oh

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