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(at)2ndQuadrant(dot)com www.2ndQuadrant.us