Re: max_standby_delay considered harmful

Tom Lane wrote:

> Taking out features after they've been in a release is very hard, even if we realize they're badly
> designed.
>   

It doesn't have to be; that's the problem the "release often" part takes 
care of.  If a release has only been out a year, and a new one comes out 
saying "oh, that thing we released for the first time in the last 
version, it didn't work as well as we'd hoped in the field; you should 
try to avoid that and use this new implementation that works better 
instead once you can upgrade", that's not only not hard, it's exactly 
what people using a X.0 release expect to happen.

I've read the message from you that started off this thread several 
times now.  Your low-level code implementation details shared later 
obviously need to be addressed.  But all of the "fundamental" and 
"fatal" issues you mentioned at the start continue to strike me as 
either situations where you don't agree with the use case this was 
designed for, or spots where you feel the userland workarounds required 
to make it work right are too onerous.  Bruce's objections seem to fall 
mainly into the latter category.

I've been wandering around talking to people about that exact 
subject--what do people want and expect from Hot Standby, and what would 
they do to gain its benefits--for over six months now, independently of 
Simon's work which did a lot of that before me too.  The use cases are 
covered as best they can be without better support from expected future 
SR features like heartbeats and XID loopback.  As for the workarounds 
required to make things work, the responses I get match what we just saw 
from Andres.  When the required details are explained, people say 
"that's annoying but I can do that", and off we go.  There are 
significant documentation issues I know need to be cleaned up here, and 
I've already said I'll take care of that as soon as freeze is really 
here and I have a stable target.  (That this discussion is still going 
on says that's not yet)

What I fail to see are problems significant enough to not ship the parts 
of this feature that are done, so that it can be used by those it is 
appropriate for, allow feedback, and make it easy to test individual 
improvements upon what's already there.  I can't make you prioritize 
based on what people are telling me.  All I can do is suggest you 
reconsider handing control over the decision to use this feature or not 
to the users of the software, so they can make their own choice.

I'm tired of arguing about this instead of doing productive work, and 
I've done all I can here to try and work within the development process 
of the community.  If talk of removing the max_standby_delay feature 
clears up, I'll happily provide my promised round of documentation 
updates, to make its limitations and associated workarounds as clear as 
they can be, within a week of being told go on that.  If instead this 
capability goes away, making those moot, I'll maintain my own release 
for the 2ndQuadrant customers who have insisted they need this 
capability if I have to.  That would be really unfortunate, because the 
only bucket I can pull time out of for that is the one I currently 
allocate to answering questions on the mailing lists here most days.  
I'd rather spend that helping out the PostgreSQL community, but we do 
need to deliver what our customers want too.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us