Skip site navigation (1) Skip section navigation (2)

Re: Insane behaviour in 8.3.3

From: "Raj Mathur ( राज =?utf-8?b?IOCkruCkvuCkpeClgeCksA==?=)" <raju(at)linux-delhi(dot)org>
To: pgsql-sql(at)postgresql(dot)org
Subject: Re: Insane behaviour in 8.3.3
Date: 2012-06-15 17:28:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-sql
On Friday 15 Jun 2012, Samuel Gendler wrote:
> On Fri, Jun 15, 2012 at 1:24 AM, Achilleas Mantzios <
> achill(at)matrix(dot)gatewaynet(dot)com> wrote:
> > And i forgot to mention, minicom term emulation quality sucks, even
> > giving simple
> > shell commands is a PITA, upgrading the whole fleet would mean bast
> > case scenario
> > minimum 21K USD for the whole fleet + suspension of all other
> > activities for two months.
> > If physical travel was involved, the cost would be increased at
> > even higher levels.
> And what is the cost of data corruption on large numbers of systems? 
> And how much to fix that, especially if multiple systems fail at the
> same time? Some things aren't free. $21K in exchange for NOT having
> had to keep systems up to date for 4 years seems like a decent
> trade.

While I agree in principle with what you're saying, this specific 
comparison would be better stated as "What is the cost of data 
corruption multiplied by the risk of that corruption occurring?"

The cost of upgrading is known and unavoidable.  The cost of data 
corruption, while probably higher (unless Achilles has an effective 
backup/restore system), needs to be factored by its probability of 

Of course, neither you nor I are in Achilles' shoes, so trying to figure 
out where they pinch is academic at best.


-- Raj
Raj Mathur                          || raju(at)kandalaya(dot)org   || GPG: || || CC68
It is the mind that moves           ||   || D17F

In response to

pgsql-sql by date

Next:From: Jasen BettsDate: 2012-06-17 12:43:36
Subject: Re: Insane behaviour in 8.3.3
Previous:From: Scott MarloweDate: 2012-06-15 16:59:05
Subject: Re: Insane behaviour in 8.3.3

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group