> 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".
PostgreSQL Experts Inc.
In response to
pgsql-hackers by date
|Next:||From: Daniel Farina||Date: 2013-01-09 01:59:43|
|Subject: Re: Cascading replication: should we detect/prevent cycles?|
|Previous:||From: Josh Berkus||Date: 2013-01-09 01:48:17|
|Subject: PL/perl should fail on configure, not make|