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

On Tue, Jan 8, 2013 at 11:51 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 8 January 2013 18:46, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> On 1/5/13 1:21 PM, Peter Geoghegan wrote:
>>>
>>> On 21 December 2012 14:08, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>>
>>>> I'm sure it's possible; I don't *think* it's terribly easy.
>>>
>>>
>>> I'm inclined to agree that this isn't a terribly pressing issue.
>>> Certainly, the need to introduce a bunch of new infrastructure to
>>> detect this case seems hard to justify.
>>
>>
>> Impossible to justify, I'd say.
>>
>> Does anyone have any objections to my adding this to the TODO list, in case
>> some clever GSOC student comes up with a way to do it *without* adding a
>> bunch of infrastructure?
>
> Daniel already did object....

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

--
fdr