On 9/25/07, Morris Goldstein <morris.x.goldstein@xxxxxxxxx> wrote:
> On 9/25/07, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote:
> > But since it hit all of your machines, and at about the same time, I
> > tend to think that someone did something to these machines that caused
> > this issue, and it's not a 7.4.x problem.
>
> I'm sure it is pilot error, and we're still trying to figure out exactly
> which pilot and what error.
>
> > Did you update / upgrade kernels, device drivers, hardware, etc...
> > What is common between all these systems besides postgresql? Was
> > there a power outage? All machines had the same admin one day who had
> > a brain cramp and did something stupid?
>
> This occurred as part of an upgrade -- new OS, kernel, drivers.
>
> > Simply put, we need more info on how this happened.
> >
>
> We've recovered. There is root cause analysis going on. The question is
> whether I can use an argument about 8.0 vs. 7.4 reliability from this fiasco
> to help us get to 8.0.
> 8.0 actually is more reliable than 7.4, I assume.
Well,if you're going to upgrade look at 8.1 as a minimum, 8.2 if possible.
I can't say for sure that 8.0, 8.1 or 8.2 would have handled this much
better, but having something like Point In Time Replication or other
forms of replication readily available could have certainly limited
your downtime in this instance.
I would highly recommend 8.2.5 as your upgrade target. Look over the
release notes for 8.0, 8.1 and 8.2.
I will say that 8.2 is noticeably faster than 7.4, and is at least as
stable for me.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
