Re: Hot Standby: Relation-specific deferred conflict resolution - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject Re: Hot Standby: Relation-specific deferred conflict resolution
Date
Msg-id 4B62B40C.9030607@kaltenbrunner.cc
Whole thread Raw
In response to Re: Hot Standby: Relation-specific deferred conflict resolution  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Hot Standby: Relation-specific deferred conflict resolution  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Heikki Linnakangas wrote:
> Simon Riggs wrote:
>> Conflict resolution improvements are important to include in this
>> release, as discussed many times. Proposal given here
>> http://archives.postgresql.org/pgsql-hackers/2009-12/msg01175.php
>> presents a viable design to improve this.
>>
>> Following patch is a complete working implementation of that design.
>> I'm still testing it, but its worth publishing as early as possible to
>> allow discussion. Not for commit, just yet, but soon.
> 
> Um, you're not considering this for 9.0, are you? I think it's time to
> concentrate on the must-fix issues and fix the rough edges in what we have.
 I agree  - this looks like a completely new feature development to me 
that tries to move the goalpost quite far for 9.0.

> 
> For example, the "can't start hot standby mode from a shutdown
> checkpoint" issue is a must-fix issue in my opinion, about 10x as
> important as this. When that was last discussed, many others agreed. I
> run into that all the time when testing streaming replication, and every
> time I go "Huh, why isn't the standby opening up for connections?", and
> then, "Ahh, it's this stupid shutdown checkpoint issue again".

Yeah I ran into that one during testing as well - and I consider it a 
serious issue

> 
> And the VACUUM FULL issue is still hanging too. And maybe you could help
> with some other things on the open items or commitfest list.

yeah and we keep finding major bugs nearly daily so I don't think we 
should add features that way now.
First is stability and reliability, optimization and new features are 
imho clearly 9.1+ material. Just calling the release 9.0 and saying "we 
do that because it is a radical change and we expect some instability" 
should NOT mean we are free to put in every feature at the last minute 
with "yeah thats fine because people expect instability anyways".


Stefan


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot Standby: Relation-specific deferred conflict resolution
Next
From: Alexey Klyukin
Date:
Subject: plperl db access documentation enhancement