On Mon, 2010-05-03 at 15:32 -0400, Stephen Frost wrote: > Simon, > > * Simon Riggs (si...@2ndquadrant.com) wrote: > > Tom's proposed behaviour (has also been proposed before) favours the > > avoid query cancellation route though could lead to huge amounts of lag. > > My impression of Tom's suggestion was that it would also be a maximum > amount of delay which would be allowed before killing off queries- not > that it would be able to wait indefinitely until no one is blocking. > Based on that, I don't know that there's really much user-seen behaviour > between the two, except in 'oddball' situations, where there's a time > skew between the servers, or a large lag, etc, in which case I think > Tom's proposal would be more likely what's 'expected', whereas what you > would get with the existing implementation (zero time delay, or far too > much) would be a 'gotcha'..
If recovery waits for max_standby_delay every time something gets in its way, it should be clear that if many things get in its way it will progressively fall behind. There is no limit to this and it can always fall further behind. It does result in fewer cancelled queries and I do understand many may like that. That is *significantly* different from how it works now. (Plus: If there really was no difference, why not leave it as is?) The bottom line is this is about conflict resolution. There is simply no way to resolve conflicts without favouring one or other of the protagonists. Whatever mechanism you come up with that favours one will, disfavour the other. I'm happy to give choices, but I'm not happy to force just one kind of conflict resolution. -- 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
