Re: Cascading replication: should we detect/prevent cycles? - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Cascading replication: should we detect/prevent cycles?
Date
Msg-id CA+U5nMKK2Uw+U_Z0QTdymr4wNhpunc25JRBsBc_Yz=X4Vcxr-A@mail.gmail.com
Whole thread Raw
In response to Re: Cascading replication: should we detect/prevent cycles?  (David Fetter <david@fetter.org>)
List pgsql-hackers
On 8 January 2013 19:53, David Fetter <david@fetter.org> wrote:
> On Tue, Jan 08, 2013 at 10:46:12AM -0800, Josh Berkus wrote:
>> On 1/5/13 1:21 PM, Peter Geoghegan wrote:
>> >On 21 December 2012 14:08, Robert Haas <robertmhaas@gmail.com> wrote:
>> >>I'm sure it's possible; I don't *think* it's terribly easy.
>> >
>> >I'm inclined to agree that this isn't a terribly pressing issue.
>> >Certainly, the need to introduce a bunch of new infrastructure to
>> >detect this case seems hard to justify.
>>
>> Impossible to justify, I'd say.
>>
>> Does anyone have any objections to my adding this to the TODO list,
>> in case some clever GSOC student comes up with a way to do it
>> *without* adding a bunch of infrastructure?
>
> I'm pretty sure the logical change stuff Andres et al. are working on
> will be able to include the originating node, which makes cycle
> detection dead simple.

That's different thing really, but I see what you mean.

The problem here is how you tell whether an indirect connection is
connected to the master. It's not just a hard problem its a transient
problem, where any one person's view of the answer might be in the
midst of changing as you measure it. So throwing an error message
might make certain cluster configs inoperable.

I'd prefer to be able to bring up a complex cluster in any order,
rather than in waves of startups all needing synchronisation to avoid
error.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it
Next
From: Alvaro Herrera
Date:
Subject: Re: Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend