Re: Changeset Extraction v7.6.1 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Changeset Extraction v7.6.1
Date
Msg-id CA+TgmoZGLKJ1GsBAGQw5jEX9_GhwNS0R4p2LN9CZ9=B=CEQEuw@mail.gmail.com
Whole thread Raw
In response to Re: Changeset Extraction v7.6.1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Changeset Extraction v7.6.1  (Peter Geoghegan <pg@heroku.com>)
Re: Changeset Extraction v7.6.1  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Mon, Feb 17, 2014 at 9:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 3. As this feature is proposed, the only plugin we'll ship with 9.4 is
>> a test_decoding plugin which, as its own documentation says, "doesn't
>> do anything especially useful."  What exactly do we gain by forcing
>> users who want to make use of these new capabilities to write C code?
>
> TBH, if that's all we're going to ship, I'm going to vote against
> committing this patch to 9.4 at all.  Let it wait till 9.5 when we
> might be able to build something useful on it.  To point out just
> one obvious problem, how much confidence can we have in the APIs
> being right if there are no usable clients?  Even if they're right,
> what benefit do we get from freezing them one release before anything
> useful is going to happen?

I actually have a lot of confidence that the APIs are almost entirely
right, except maybe for the snapshot-related stuff and possibly one or
two other minor details.  And I have every confidence that 2ndQuadrant
is going to put out decoding modules that do useful stuff.  I also
assume Slony is going to ship one at some point.  EnterpriseDB's xDB
replication server will need one, so someone at EDB will have to go
write that.  And if Bucardo or Londiste want to use this
infrastructure, they'll need their own, too.  What I don't understand
is why it's cool to make each of those replication solutions bring its
own to the table.  I mean if they want to, so that they can generate
exactly the format they want with no extra overhead, sure, cool.  What
I don't understand is why we're not taking the test_decoding module,
polishing it up a little to produce some nice, easily
machine-parseable output, calling it basic_decoding, and shipping
that.  Then people who want something else can build it, but people
who are happy with something basic will already have it.

What I actually suspect is going to happen if we ship this as-is is
that people are going to start building logical replication solutions
on top of the test_decoding module even though it explicitly says that
it's just test code.  This is *really* cool technology and people are
*hungry* for it.  But writing C is hard, so if there's not a polished
plugin available, I bet people are going to try to use the
not-polished one.  I think we try to get out ahead of that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Need to update this comment in xlog.c?
Next
From: Peter Geoghegan
Date:
Subject: Re: Changeset Extraction v7.6.1