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

From Tom Lane
Subject Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)
Date
Msg-id 4307.1350331420@sss.pgh.pa.us
Whole thread Raw
In response to Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)  (Andres Freund <andres@2ndquadrant.com>)
Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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?

> Clearly, core needs to go first.  However, before we commit, I would
> like to hear the Slony guys say something like this: We read the
> documentation that is part of this patch and if the feature behaves as
> advertised, we believe we will be able to use it in place of the
> change-capture mechanism that we have now, and that it will be at
> least as good as what we have now if not a whole lot better.

> If they say something like "I'm not sure we have the right design for
> this" or "this wouldn't be sufficient to replace this portion of what
> we have now because it lacks critical feature X", I would be very
> concerned about that.

The other point here is that core code without any implemented use-cases
is unlikely to be worth a tinker's damn.  Regardless of what time-frame
the Slony guys are able to work on, I think we need to see working code
(of at least prototype quality) before we believe that we've got it
right.  Or if not code from them, code from some other replication
project.

A possibly-useful comparison is to the FDW APIs we've been slowly
implementing over the past couple releases.  Even though we *did* have
some use-cases written right off the bat, we got it wrong and had to
change it in 9.2, and I wouldn't bet against having to change it again
in 9.3 (even without considering the need for extensions for non-SELECT
operations).  And, despite our very clear warnings that all that stuff
was in flux, people have been griping because the APIs changed.

So if we ship core hooks for logical replication in advance of proof
that they're actually usable by at least one (preferably more than one)
replication project, I confidently predict that they'll be wrong and
will need revision and the potential users will complain about the
API instability.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: Truncate if exists
Next
From: Christopher Browne
Date:
Subject: Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)