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
waitingfor, plus one that reported that last timestamp seen in the WAL, than all those different cancellation policies
couldbe 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
usefulpolicies 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
algorithmswouldn'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
knowledgeon the user's side about potential pitfalls, asking those users to install the plugin from contrib shouldn't
betoo much to ask for.
>
> This way, users who really need something more sophisticated than recovery wins always or standby wins always are
giventhe tools they need *if* they're willing to put in the extra effort. For those who don't, offering
max_standby_delayprobably 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