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: 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-01 07:53:38
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Wed, Sep 1, 2010 at 2:33 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Once we're done with that, all the big questions are still left.

Yeah, let's discuss about those topics :)

> How to configure it?

Before discussing about that, we should determine whether registering
standbys in master is really required. It affects configuration a lot.
Heikki thinks that it's required, but I'm still unclear about why and

Why do standbys need to be registered in master? What information
should be registered?

> What does synchronous replication mean, when is a transaction
> acknowledged as committed?

I proposed four synchronization levels:

1. async
  doesn't make transaction commit wait for replication, i.e.,
  asynchronous replication. This mode has been already supported in

2. recv
  makes transaction commit wait until the standby has received WAL

3. fsync
  makes transaction commit wait until the standby has received and
  flushed WAL records to disk

4. replay
  makes transaction commit wait until the standby has replayed WAL
  records after receiving and flushing them to disk

OTOH, Simon proposed the quorum commit feature. I think that both
is required for various our use cases. Thought?

> What to do if a standby server dies and never
> acknowledges a commit?

The master's reaction to that situation should be configurable. So
I'd propose new configuration parameter specifying the reaction.
Valid values are:

- standalone
  When the master has waited for the ACK much longer than the timeout
  (or detected the failure of the standby), it closes the connection
  to the standby and restarts transactions.

- down
  When that situation occurs, the master shuts down immediately.
  Though this is unsafe for the system requiring high availability,
  as far as I recall, some people wanted this mode in the previous


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Thom BrownDate: 2010-09-01 08:06:48
Subject: Re: array_agg() NULL Handling
Previous:From: Pavel StehuleDate: 2010-09-01 07:30:08
Subject: Re: array_agg() NULL Handling

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