On May 6, 2010, at 11:26 , Dimitri Fontaine wrote: > Greg Smith <g...@2ndquadrant.com> writes: >> If you need a script that involves changing a server setting to do >> something, that translates into "you can't do that" for a typical DBA. The >> idea of a program regularly changing a server configuration setting on a >> production system is one you just can't sell. That makes this idea >> incredibly more difficult to use in the field than any of the workarounds >> that cope with the known max_standby_delay issues. > > I still think that the best API we can do in a timely fashion for 9.0 > is: > > standby_conflict_winner = replay|queries > > pg_pause_recovery() / pg_resume_recovery() > > It seems to me those two functions are only exposing existing facilities > in the code, so that's more an API change that a new feature > inclusion. Of course I'm certainly wrong. But the code has already been > written.
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. best regards, Florian Pflug
smime.p7s
Description: S/MIME cryptographic signature
