Andrew Sullivan wrote:

>On Wed, Nov 02, 2005 at 08:21:49AM -0500, Jan Wieck wrote:
>  
>
>>I just wonder what the value in that MOVE SET "on corruption" is. We can 
>>    
>>
>
>There isn't one, which is the point.  If the database is really
>corrupted, you're hosed.  You _can_ do a MOVE SET though for maybe 5
>databases where you have more-strict SLAs than the rest of them, when
>you can tell the hardware is failing.  Imagine you have a 2-disk RAID that
>just lost one disk.  5 of the databases have a lot of traffic, while
>the other 45 are basically read-only back ends for blogs.  Move the
>5: it's safer, and in the worst case (the other disk fails), you have
>to do failover for the node, but you won't have lost much.  There are
>several scenarios I can imagine like this.
>  
>
This points back to one paragraph of Phillipe's, which, to my eye, has
some ambiguity:

============================================================
I was thinking about the eventual corruption of a database, not of
PostgreSQL.
If a database happens to be corrupted, only this one need failover. In
the case of a huge database,
everything is concerned by the failure (and by the failover procedure
!), which is a *pain*...
============================================================

It is not entirely clear that we all have an identical understanding as
to what he meant by "corruption."

The way I took it was that there was some filesystem level problem; if
that is a correct reading, then it seems to me that it would
simultaneously affect all 50 databases if they share the same
{filesystem|disk cluster|database cluster} irrespective of how
replication were configured.  In effect, 50 eggs are all in one basket,
and if one of them falls out, the hole is big enough that they are all
in the same jeapordy.

If the possible problem is "runaway bad query," then I suppose that
having 50 databases would buy *some* protection, although the cost of
100 slons x several backends per slon shows that the pricetag is
prohibitively high.

The scenario where the cost seems regrettable is where someone is using
a PostgreSQL in an ISP web hosting context, where it would certainly be
nice to have 50 customers' data in separate databases.  Slony-I really
isn't attuned to that scenario.

But if the load on the system is low enough that you can afford to have
50 databases hosted on one postmaster, then it seems improbable that
load balancing is one of the goals.  I think, for that scenario, I'd
point to PITR as being "the answer."  Slony-I isn't intended to be the
answer to every problem.