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

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

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(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-09 01:51:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

> To briefly reiterate my objection, I observed that one may want to
> enter a case of cyclicality on a temporary basis -- to assist with
> some intermediate states in remastering, and it'd be nice if Postgres
> didn't try to get in the way of that.

I don't think it *should* fail.  I think it should write a WARNING to
the logs, to make it easy to debug if the cycle was created accidentally.

> I would like to have enough reporting to be able to write tools that
> detect cyclicity and other configuration error, and I think that may
> exist already in recovery.conf/its successor in postgresql.conf.  A
> notable problem here is that UDFs, by their mechanical nature, don't
> quite cover all the use cases, as they require the server to be
> running and available for hot standby to run.  It seems like reading
> recovery.conf or its successor is probably the best option here.

Well, pg_conninfo will still be in postgresql.conf.  But that doesn't
help you if you're playing fast and loose with virtual IP addresses ...
and arguably, people using Virtual IPs are more likely to accidentally
create a cycle.

Anyway, I'm not saying we solve this now.  I'm saying, "put it on the
TODO list in case someone has time/an itch to scratch".

Josh Berkus
PostgreSQL Experts Inc.

In response to


pgsql-hackers by date

Next:From: Daniel FarinaDate: 2013-01-09 01:59:43
Subject: Re: Cascading replication: should we detect/prevent cycles?
Previous:From: Josh BerkusDate: 2013-01-09 01:48:17
Subject: PL/perl should fail on configure, not make

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