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
