On Mon, 2010-05-03 at 13:13 -0400, Stephen Frost wrote:
> Perhaps you could speak to the specific user
> experience difference that you think there would be from this change?
The difference is really to do with the weight you give to two different
considerations
* avoid query cancellations
* avoid having recovery fall behind, so that failover time is minimised
Some people recognise the trade-offs and are planning multiple standby
servers dedicated to different roles/objectives.
Some people envisage Hot Standby as a platform for running very fast
SELECTs, for which retrying the query is a reasonable possibility and
for whom keeping the standby as up-to-date as possible is an important
consideration from a data freshness perspective. Others view HS as a
weapon against long running queries.
My initial view was that the High Availability goal/role should be the
default or most likely mode of operation. I would say that the current
max_standby_delay favours the HA route since it specifically limits the
amount by which server can fall behind.
Tom's proposed behaviour (has also been proposed before) favours the
avoid query cancellation route though could lead to huge amounts of lag.
I'm happy to have both options because I know this is a trade-off that
solution engineers want to have control of, not something we as
developers can choose ahead of time.
-- Simon Riggs www.2ndQuadrant.com
