On Mon, Jun 8, 2009 at 7:34 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I see that you've carefully not quoted Greg's remark about "mechanism >> not policy" with which I completely agree. > > Mechanism should exist to support useful policy. I don't believe that > the proposed switch has any real-world usefulness.
I guess I agree that it doesn't seem to make much sense to trigger failover on a DB crash, as the OP suggested. The most likely cause of a DB crash is probably a software bug, in which case failover isn't going to help (won't you just trigger the same bug on the standby server?). The case where you'd probably want to do failover is when the whole server has gone down to a hardware or power failure, in which case your hypothetical home-grown supervisor process won't be able to run anyway. But I'm still not 100% convinced that the proposed mechanism is useless. There might be other reasons to want to get control in the event of a crash. You might want to page the system administrator, or trigger a filesystem snapshot so you can go back and do a post-mortem. (The former could arguably be done just as well by scanning the log file for the relevant log messages, I suppose, but the latter certainly couldn't be, if your goal is to get a snapshot before recovery is done.) But maybe I'm all wet... ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
