Re: Shared disk storage - Mailing list pgsql-general

From Jim C. Nasby
Subject Re: Shared disk storage
Date
Msg-id 20050906220141.GY60481@pervasive.com
Whole thread Raw
In response to Re: Shared disk storage  (Bruno Wolff III <bruno@wolff.to>)
Responses Re: Shared disk storage
List pgsql-general
On Tue, Sep 06, 2005 at 02:58:52PM -0500, Bruno Wolff III wrote:
> On Tue, Sep 06, 2005 at 13:47:42 -0500,
>   "Jim C. Nasby" <jnasby@pervasive.com> wrote:
> > On Tue, Sep 06, 2005 at 10:13:33AM -0500, Bruno Wolff III wrote:
> > > On Mon, Sep 05, 2005 at 12:20:24 +0300,
> > >   Peter Nixon <listuser@peternixon.net> wrote:
> > > > Hi List
> > > >
> > > > Does anyone have any comments, HOWTOs and experience running multiple
> > > > Postgres servers with a shared disk (SAN) in a Hot standby configuration?
> > > >
> > > > Can someone please point me in the direction of any docs on this subject?
> > >
> > > Be sure to have some failsafe to prevent two servers from running at the
> > > same time on the same data. If that ever happens your database will be hosed.
> >
> > I thought PostgreSQL already had such a safeguard? Or is it only against
> > starting two backends against the same PGDATA on the same machine?
>
> Yes, but it is more likely to have problems when there are two machines
> involved. One is that the file may not be on the cross mounted file
> system (on FC4 it is in /var/run) and even if it is on the cross mounted
> file system, there is a good chance the lock file will appear to be stale
> because the process id is for the other machine. I am not sure if there are
> other gotchas, but you definitely want to be careful, since a mistake is
> going to defeat the purpose of having the hot spares.

Maybe it would be better to keep this in PGDATA (or even a duplicate
copy). Holding a write lock on the file should also help ensure that you
can tell if it's stale or not.

I realize this probably still isn't perfect, but it's probably better
than forcing users to find an external means of locking out the other
backend.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: SLOOOOOOOW
Next
From: Tom Lane
Date:
Subject: Re: Help with row locks on 7.4 to 8.0 migration