Re: Postgres over stand-alone disk array?

From: Andrew Sullivan <andrew(at)libertyrms(dot)info>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Postgres over stand-alone disk array?
Date: 2002-11-08 15:30:52
Message-ID: 20021108103052.D32733@mail.libertyrms.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Mon, Nov 04, 2002 at 02:49:32PM -0600, Adam Erickson wrote:
> Has anyone used postgres w/ an external disk array? I'm sure a single
> postgres instance would work fine with one.

Yes.

> While researching the server clustering techniques of other RDBMS I
> came upon Oracle 9's "RAC" clustering. It appears to use a stand
> alone array for the real storage and multiple "head" servers for
> the actual work. (This may be totally inaccurate depending on how
> late it was when I read this)

That's more or less right. ORAC is not true redundancy, in that the
database servers all talk to shared storage; so if the sotrage goes
away, poof! (Of course, the Riaght Answer in that case is to use
ultra-redundant storage. Protecting against triple and quadruple
points of failure is a pretty rare requirement.)

> What would happen if the same thing was tried with Postgres?

You would very probably corrupt the database, and leave it in a
totally unusable state.

Oracle does it by using some very clever interlocking and
contention-arbitrating technology (rumour has it that it's the same
thing that VMS relied on. There's a reason banks liked VMS so much).
As I understand it, you'd need some sort of ability to share shared
memory for PostgreSQL to be able to do this (this problem is what
prevents MOSIX clusters and , it appears, SGI's Origin -- i.e. ccNUMA
-- machines from being good candidate platforms for Postgres). Don't
take my word for it, though, as I'm not a Postgres hacker.

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew(at)libertyrms(dot)info> M2P 2A8
+1 416 646 3304 x110

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message A.M. 2002-11-08 17:31:05 FATAL 1: Sorry, too many clients already
Previous Message dropkick 2002-11-08 14:11:17 Recoverying DB from file(s)