Re: Configuring synchronous replication

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Heikki Linnakangas <heikki(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Configuring synchronous replication
Date: 2010-09-17 11:44:33
Message-ID: AANLkTi=j10+R4Gm_hmybZx_3+dEZGSHkxS+2dNNS0vXe@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Fri, Sep 17, 2010 at 7:31 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> The only thing standby registration allows you to do is know whether
> there was supposed to be a standby there, but yet it isn't there now. I
> don't see that point as being important because it seems strange to me
> to want to wait for a standby that ought to be there, but isn't anymore.
> What happens if it never comes back? Manual intervention required.
>
> (We agree on how to handle a standby that *is* "connected", yet never
> returns a reply or takes too long to do so).

Doesn't Oracle provide a mode where it shuts down if this occurs?

> The absence of registration in my patch makes some things easier and
> some things harder. For example, you can add a new standby without
> editing the config on the master.

That's actually one of the reasons why I like the idea of
registration. It seems rather scary to add a new standby without
editing the config on the master. Actually, adding a new fully-async
slave without touching the master seems reasonable, but adding a new
sync slave without touching the master gives me the willies. The
behavior of the system could change quite sharply when you do this,
and it might not be obvious what has happened. (Imagine DBA #1 makes
the change and DBA #2 is then trying to figure out what's happened -
he checks the configs of all the machines he knows about and finds
them all unchanged... head-scratching ensues.)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Fujii Masao 2010-09-17 11:56:59 Re: Configuring synchronous replication
Previous Message Robert Haas 2010-09-17 11:38:22 Re: Configuring synchronous replication

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2010-09-17 11:56:18 Re: Serializable Snapshot Isolation
Previous Message Robert Haas 2010-09-17 11:38:22 Re: Configuring synchronous replication