Re: BUG #7803: Replication Problem(no master is there) - Mailing list pgsql-bugs

From Heikki Linnakangas
Subject Re: BUG #7803: Replication Problem(no master is there)
Date
Msg-id 50EFCFF5.4040109@vmware.com
Whole thread Raw
In response to BUG #7803: Replication Problem(no master is there)  (katsumata.tomonari@po.ntts.co.jp)
Responses Re: BUG #7803: Replication Problem(no master is there)
Re: BUG #7803: Replication Problem(no master is there)
List pgsql-bugs
On 11.01.2013 06:09, katsumata.tomonari@po.ntts.co.jp wrote:
> The following bug has been logged on the website:
>
> Bug reference:      7803
> Logged by:          Tomonari Katsumata
> Email address:      katsumata.tomonari@po.ntts.co.jp
> PostgreSQL version: 9.2.2
> Operating system:   RHEL 5.3 x86_64
> Description:
>
> hi, I'm playing with Synchronous Replication on PostgreSQL 9.2.2.
> And I saw a strange behavior.

Unless you left out something, the configuration you described actually
sets up asynchronous replication.

> =================================================================
> [issues]
> two standbys are connected on each other, but
> no master is there.
>...
> =================================================================
>
> I did not see the situation like above on PostgreSQL 9.1.7.
>
> Is this intended change?

In 9.1, this scenario was impossible because you could not connect a
standby to another standby. In 9.2, that's allowed. It's a new feature
called "cascading replication", see
http://www.postgresql.org/docs/9.2/static/warm-standby.html#CASCADING-REPLICATION.

With that feature, it's indeed possible to form a cycle of standby
servers connected to each other. There was just a long discussion on
pgsql-hackers on whether we should try to detect that scenario [1], but
the consensus seems to be that we should not. It would be difficult to
implement such detection, and sometimes it's useful to have such a
cycle, as a transient state at a failover, for example.

So the bottom line is that this is an intended change, and the admin
will just have to avoid doing that.

This makes me wonder if there should be a GUC to forbid cascading
replication, though. If you don't want to do cascading replication
(which is quite rare, I'd say), you could just disable it to avoid a
situation like this.

[1] http://archives.postgresql.org/pgsql-hackers/2012-12/msg01134.php

- Heikki

pgsql-bugs by date:

Previous
From: katsumata.tomonari@po.ntts.co.jp
Date:
Subject: BUG #7803: Replication Problem(no master is there)
Next
From: Simon Riggs
Date:
Subject: Re: BUG #7803: Replication Problem(no master is there)