Re: what to revert - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: what to revert
Date
Msg-id CAMsr+YEfQDqs7bA8a49S7J8hZR3E44C09xt48ru8Mq1t9MAivA@mail.gmail.com
Whole thread Raw
In response to Re: what to revert  (Euler Taveira <euler@timbira.com.br>)
Responses Re: what to revert  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 4 May 2016 at 13:03, Euler Taveira <euler@timbira.com.br> wrote:
 
Question is: is the actual code so useless that it can't even be a 1.0
release?

What's committed suffers from a design problem and cannot work correctly, nor can it be fixed without an API change and significant revision. The revised version I posted yesterday is that fix, but it's new code just before beta1. It's pretty much equivalent to reverting the original patch and then adding a new, corrected implementation. If considered as a new feature it'd never be accepted at this stage of the release.

A lot of (complex) features were introduced with the notion
that will be improved in the next version.

Absolutely, and this is what Petr and I (and Andres, though less actively lately) have both been trying to do in terms of building on logical decoding to add logical replication support. This is one small piece of that work.

It's a pity since I'll have to maintain a patchset for 9.6 for people who need physical HA support for their logical decoding and replication clients. But it doesn't change the WAL format or catalogs, so it's pretty painless to swap into existing installations. It could be worse.

However, if the code is buggy
or there are serious API problems, revert them.

Exactly. That's the case here. 

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

pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: Accidentally parallel unsafe functions
Next
From: Andres Freund
Date:
Subject: Re: [BUGS] Breakage with VACUUM ANALYSE + partitions