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

From David Fetter
Subject Re: Cascading replication: should we detect/prevent cycles?
Date
Msg-id 20130108195338.GC12730@fetter.org
Whole thread Raw
In response to Re: Cascading replication: should we detect/prevent cycles?  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Cascading replication: should we detect/prevent cycles?
List pgsql-hackers
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.

Other restrictions on the graph like, "must be a tree" might be more
complicated.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate



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: Andres Freund
Date:
Subject: Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it