On Tue, Jan 8, 2013 at 5:51 PM, Josh Berkus <j...@agliodbs.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
