Skip site navigation (1) Skip section navigation (2)

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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Subject: Re: Cascading replication: should we detect/prevent cycles?
Date: 2013-01-08 20:30:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2013-01-08 20:36:19
Subject: Re: Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend
Previous:From: Tom LaneDate: 2013-01-08 20:27:23
Subject: Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group