Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)
Дата
Msg-id CAFNqd5UoqqFrr-PuYugeSs=VuDmDnfd1gGhE=5Rm7dmiv5MeRw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)  (Peter Geoghegan <peter@2ndquadrant.com>)
Ответы Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)
Список pgsql-hackers
On Mon, Oct 15, 2012 at 3:18 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 15 October 2012 19:19, Bruce Momjian <bruce@momjian.us> wrote:
>> I think Robert is right that if Slony can't use the API, it is unlikely
>> any other replication system could use it.
>
> I don't accept that. Clearly there is a circular dependency, and
> someone has to go first - why should the Slony guys invest in adopting
> this technology if it is going to necessitate using a forked Postgres
> with an uncertain future? That would be (with respect to the Slony
> guys) a commercial risk that is fairly heavily concentrated with
> Afilias.

Yep, there's something a bit too circular there.

I'd also not be keen on reimplementing the "Slony integration" over
and over if it turns out that the API churns for a while before
stabilizing.  That shouldn't be misread as "I expect horrible amounts
of churn", just that *any* churn comes at a cost.  And if anything
unfortunate happens, that can easily multiply into a multiplicity of
painfulness(es?).
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)