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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
