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

From Tomonari Katsumata
Subject Re: BUG #7803: Replication Problem(no master is there)
Date
Msg-id 50F00301.1060301@po.ntts.co.jp
Whole thread Raw
In response to Re: BUG #7803: Replication Problem(no master is there)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: BUG #7803: Replication Problem(no master is there)
List pgsql-bugs
Hi,

>> 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.
>

Thank you for the comment.
I was thinking to promote one of them and set
synchronous_standby_names = 'sby' and reload configure file.
Before that, I noticed the issue.


>> =================================================================
>> [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.

Sorry, I had not read the discussion and have reported it again.
And I understand it's hard to detect cyclic situation.

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

OK.
This situation was made by playing, so it's not big problem for now.

>
> 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.

I'm not sure but what about adding the parameter("cascade_mode") on
recovery.conf ?
The parameter represents a will to connect to standby server when
starting as standby.
If the parameter is set to on, connect to a server forcely like
PostgreSQL 9.2,
and if the parameter is set to off, connect to the another standby server is
refused like PostgreSQL 9.1.


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

regards,
--------
NTT Software Corporation
  Tomonari Katsumata

pgsql-bugs by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: BUG #7803: Replication Problem(no master is there)
Next
From: Dave Cramer
Date:
Subject: Re: [JDBC] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception