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

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

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Josh Berkus <josh(at)agliodbs(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:59:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jan 8, 2013 at 5:51 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Daniel,
>> 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.

Well, in the conversation so long ago that was more openly considered,
which may not be true in the present era...just covering my old tracks

>> 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.

That's a good point. Even simpler than virtual-IP is DNS, wherein the
resolution can be rebound, but a pre-existing connection to an old IP
will happily remain, and will be hard to know that from
postgresql.conf and friends.  I guess that means the hard case is when
 hot standby is not (yet) on, but the server is actively recovering
WAL...UDFs are out, and scanning postgresql.conf is not necessarily an
accurate picture of the situation.


In response to

pgsql-hackers by date

Next:From: Josh BerkusDate: 2013-01-09 02:01:55
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Previous:From: Josh BerkusDate: 2013-01-09 01:51:58
Subject: Re: Cascading replication: should we detect/prevent cycles?

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