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.gritt...@wicourts.gov> wrote:
"Kolb, Harald (NSN - DE/Munich)" <harald.k...@nsn.com> wrote:
From: ext Tom Lane [mailto:t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
