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

From Christopher Browne
Subject Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)
Date
Msg-id CAFNqd5UoqqFrr-PuYugeSs=VuDmDnfd1gGhE=5Rm7dmiv5MeRw@mail.gmail.com
Whole thread Raw
In response to Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)  (Andres Freund <andres@2ndquadrant.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)
Next
From: Andres Freund
Date:
Subject: Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)