On Thu, 2010-05-06 at 13:46 +0200, Florian Pflug wrote:
> On May 6, 2010, at 12:48 , Simon Riggs wrote:
> > On Thu, 2010-05-06 at 11:36 +0200, Florian Pflug wrote:
> >> If there was an additional SQL-callable function that returned the 
> >> backends the recovery process is currently waiting for, plus one that 
> >> reported that last timestamp seen in the WAL, than all those different 
> >> cancellation policies could be implemented as daemons that monitor 
> >> recovery and kill backends as needed, no?
> >> 
> >> That would allow people to experiment with different cancellation 
> >> policies, and maybe shed some light on what the useful policies are in 
> >> practice.
> > 
> > It would be easier to implement a conflict resolution plugin that is
> > called when a conflict occurs, allowing users to have a customisable
> > mechanism. Again, I have no objection to that proposal.
> 
> True, providing a plugin API would be even better, since no SQL callable API 
> would have to be devised, and possible algorithms wouldn't be constrained by 
> such an API's limitations.
> 
> The existing max_standby_delay logic could be moved to such a plugin, living 
> in contrib. Since it was already established (I believe) that the existing 
> max_standby_delay logic is sufficiently fragile to require significant 
> knowledge on the user's side about potential pitfalls, asking those users to 
> install the plugin from contrib shouldn't be too much to ask for.
> 
> This way, users who really need something more sophisticated than recovery 
> wins always or standby wins always are given the tools they need *if* they're 
> willing to put in the extra effort. For those who don't, offering 
> max_standby_delay probably does more harm than good anyway, so nothing is 
> lost by not offering it in the first place.

No problem from me with that approach.

As long as 9.0 ships with the current capability to enforce
max_standby_delay, I have no problem.

-- 
 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

Reply via email to