On 4 May 2016 at 01:12, Peter Geoghegan <pg@heroku.com> wrote:
On Tue, May 3, 2016 at 9:58 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > As its committer, I tend to agree about reverting that feature. Craig > was just posting some more patches, and I have the pg_recvlogical > changes here (--endpos) which after some testing are not quite looking > ready to go -- plus we still have to write the actual Perl test scripts > that would use it. Taken together, this is now looking to me a bit > rushed, so I prefer to cut my losses here and revert the patch so that > we can revisit it for 9.7.
I think it's a positive development that we can take this attitude to reverting patches. It should not be seen as a big personal failure, because it isn't. Stigmatizing reverts incentivizes behavior that leads to bad outcomes.
Indeed. Being scared to revert also makes the barrier to committing something and getting it into more hands, for longer, under a variety of different conditions higher. Not a ton of help with this particular feature but quite important with others.
While I'm personally disappointed by this outcome, I also can't really disagree with it. The whole area is a bit of a mess and hard to work on, and as demonstrated my understanding of it when I wrote the original patch was incomplete. We could commit the rewritten function, but ... rewriting a feature just before beta1 probably says it's just not baked yet, right?
The upside of all this is that now I have a decent picture of how it should all look and how timeline following, failover capability etc can be introduced in a staged way. I'd also like to get rid of the use of various globals to pass timeline information "around" the walsender and share more of the logic between the code paths.