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

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

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

--
fdr