| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | "Kolb, Harald (NSN - DE/Munich)" <harald(dot)kolb(at)nsn(dot)com> |
| Cc: | ext Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Czichy, Thoralf (NSN - FI/Helsinki)" <thoralf(dot)czichy(at)nsn(dot)com> |
| Subject: | Re: postmaster recovery and automatic restart suppression |
| Date: | 2009-06-09 19:21:56 |
| Message-ID: | 1244575316.15799.355.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2009-06-09 at 20:59 +0200, Kolb, Harald (NSN - DE/Munich) wrote:
> There are some good reasons why a switchover could be an appropriate
> means in case the DB is facing troubles. It may be that the root cause
> is not the DB itsself, but used resources or other things which are
> going crazy and hit the DB first ( we've seen a lot of these
> unbelievable things which made us quite sensible for robustness
> aspects). Therefore we want to have control on the DB recovery.
> If you don't want to see this option as a GUC parameter, would it be
> acceptable to have it as a new postmaster cmd line option ?
Even if you had this, you still need to STONITH just in case the
failover happens by mistake.
If you still have to take an action to be certain, what is the point of
the feature?
Most losses of availability are caused by human error and this seems
like one more way to blow your remaining toes off.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2009-06-09 19:53:26 | Re: postmaster recovery and automatic restart suppression |
| Previous Message | Tom Lane | 2009-06-09 19:20:21 | Re: postmaster recovery and automatic restart suppression |