Re: Cascade replication - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Cascade replication
Date
Msg-id CA+U5nMKciZ6gZeQ060mn_UsmS45QdjAva-uBRMzjHpV7pU1mOA@mail.gmail.com
Whole thread Raw
In response to Cascade replication  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Cascade replication
List pgsql-hackers
On Tue, Jun 14, 2011 at 6:08 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

>> The standby must not accept replication connection from that standby itself.
>> Otherwise, since any new WAL data would not appear in that standby,
>> replication cannot advance any more. As a safeguard against this, I introduced
>> new ID to identify each instance. The walsender sends that ID as the fourth
>> field of the reply of IDENTIFY_SYSTEM, and then walreceiver checks whether
>> the IDs are the same between two servers. If they are the same, which means
>> that the standby is just connecting to that standby itself, so walreceiver
>> emits ERROR.

Thanks for waiting for review.

This part of the patch is troubling me. I think you have identified an
important problem, but this solution doesn't work fully.

If we allow standbys to connect to other standbys then we have
problems with standbys not being connected to master. This can occur
with a 1-step connection, as you point out, but it could also occur
with a 2-step, 3-step or more connection, where a circle of standbys
are all depending upon each other. Your solution only works for 1-step
connections. "Solving" that problem in a general sense might be more
dangerous than leaving it alone. I think we should think some more
about the issues there and approach them as a separate problem.

I think we should remove that and just focus on the main problem, for
now. That will make it a simpler patch and easier to commit.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: flex on win64 - workaround for "flex: fatal internal error, exec failed"
Next
From: Radosław Smogura
Date:
Subject: Re: Crash dumps