Re: postmaster recovery and automatic restart suppression
От | Fujii Masao |
---|---|
Тема | Re: postmaster recovery and automatic restart suppression |
Дата | |
Msg-id | 3f0b79eb0906092333j51e33ffboc4b5f9346e84f098@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postmaster recovery and automatic restart suppression (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
Hi, On Wed, Jun 10, 2009 at 4:21 AM, Simon Riggs<simon@2ndquadrant.com> wrote: > > 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. Yes. On second thought, probably we should solve this kind of problem outside of Postgres. > Is there a possibility to deactivate the restart and to force the postmaster > to simply exit at the end ? > The background is that we will have a watchdog process which will in > this case perform a fast switchover to the standby side (in case of > syncronous replication) or will restart the db by its own and in addition > will perform some specific actions. To return to the original Harald's problem, the watchdog process can shoot postmaster before doing the next action. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: