Greg Stark wrote:
> Eh? That's not what I meant at all. Actually it's kind of the exact
> opposite of what I meant.
>
Sorry about that--I think we just hit one of those language usage drift
bits of confusion. "Sit in the corner" has a very negative tone to it
in US English and I interpreted your message badly as a result. A
Google search for images using that phrase will quickly show you what I
mean.
> What I meant was that your description of the "High Availability first
> and foremost" is only one possible use case. Simon in the past
> expressed the same single-minded focus on that use case. It's a
> perfectly valid use case and I would probably agree if we had to
> choose just one it would be the most important.
>
Sure, there are certainly others, and as much as possible more
flexibility here is a good thing. What I was suggesting is that if the
only good way to handle long-running queries has no choice but to
sacrifice high-availability, which is is the situation if
max_standby_delay is the approach you use, then the most obvious users
for this feature are not being well served by that situation. I would
guess a large portion of the users looking forward to Hot Standby are in
the "have an underutilized high-availability standby I'd like to use for
offloading long running reports", and if there is no way to serve them
well this feature is missing the mark a bit.
You really can't do any better without better master/standby integration
though, and as pointed out a couple of times here that was considered
and just not followed through on yet. I'm increasingly concerned that
nothing else will really do though.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
