Re: Cascading replication: should we detect/prevent cycles?

On 8 January 2013 19:53, David Fetter <david(at)fetter(dot)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(at)gmail(dot)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