Re: postmaster recovery and automatic restart suppression
От | Greg Stark |
---|---|
Тема | Re: postmaster recovery and automatic restart suppression |
Дата | |
Msg-id | CD358425-972D-4B23-940F-89999230CB48@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: postmaster recovery and automatic restart suppression ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Список | pgsql-hackers |
Not really since once you fail over you may as well stop the rebuild since you'll have to restore the whole database. Moreover wouldn't that have to be a manual decision? The closest thing I can come to a use case would be if you run a very large cluster with hundreds of read-only replicas. If one has problems you would rather the load balancer notice and take it out of rotation immediately rather than have it flap and continue to cause problems. Even there it would be dicey since a software bug could easily cause all your replicas to start misbehaving simultaneously. It would suck to see them all shut down one by one... -- Greg On 9 Jun 2009, at 20:53, "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > "Kolb, Harald (NSN - DE/Munich)" <harald.kolb@nsn.com> wrote: >>> From: ext Tom Lane [mailto:tgl@sss.pgh.pa.us] > >>> Mechanism should exist to support useful policy. I don't believe >>> that the proposed switch has any real-world usefulness. > >> 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 > > Would an example of this be that one drive in a RAID has gone bad and > the hot spare rebuild has been triggered, leading to poor performance > for a while? Is that the sort of issue where you see value? > > -Kevin
В списке pgsql-hackers по дате отправления: