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

On Monday, October 15, 2012 10:08:28 PM Christopher Browne wrote:
> 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?).

Well, as a crosscheck, could you list your requirements?

Do you need anything more than outputting data in a format compatible to whats 
stored in sl_log_*? You wouldn't have sl_actionseq, everything else should be 
there (Well, you would need to do lookups to get the tableid, but thats not 
really much of a problem). The results would be ordered in complete 
transactions, in commit order.

I guess the other tables would stay as they are as they contain the "added 
value" of slony?

Greetings,

Andres
-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services