Re: Cascading replication: should we detect/prevent cycles?
От | Daniel Farina |
---|---|
Тема | Re: Cascading replication: should we detect/prevent cycles? |
Дата | |
Msg-id | CAAZKuFa+PR+yZT1=YuoZv-06sOdDVdk-T7jsB6NXMjLnXSwqpw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Cascading replication: should we detect/prevent cycles? (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Cascading replication: should we detect/prevent cycles?
|
Список | pgsql-hackers |
On Tue, Jan 8, 2013 at 11:51 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 8 January 2013 18:46, Josh Berkus <josh@agliodbs.com> wrote: >> On 1/5/13 1:21 PM, Peter Geoghegan wrote: >>> >>> On 21 December 2012 14:08, Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: