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

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

From: David Fetter <david(at)fetter(dot)org>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>,Robert Haas <robertmhaas(at)gmail(dot)com>,Simon Riggs <simon(at)2ndquadrant(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 19:53:38
Message-ID: 20130108195338.GC12730@fetter.org (view raw or flat)
Thread:
Lists: 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(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.

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

Cheers,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Andres FreundDate: 2013-01-08 20:00:22
Subject: Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it
Previous:From: Tom LaneDate: 2013-01-08 19:53:29
Subject: Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it

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