On Thu, Sep 8, 2011 at 20:40, Thom Brown <t...@linux.com> wrote: > Hi all, > > I've come across a PostgreSQL set up where there are 2 servers, each > with the same version of PostgreSQL on, both mounting the same SAN > onto their respective file systems. It was intended that only 1 of > the servers would be running an instance of PostgreSQL at a time as > they both point to the same pgdata. This was dubbed a "high
<snip> > Would there be a way to prevent this abhorrent scenario from coming > into existence? One idea is to have a configuration option to be > strict about the presence of a pid file in the data directory, and > force manual intervention, but I'm not sure this would solve the > problem in most cases where this problem exists as someone would have > had to specifically sought out the option and set it. It might also > encourage some to just delete the pid file thinking that would make > the nasty errors go away. There are plenty of clustering products out there that are really designed for one thing pimarily, and that's dealing with this kind of fencing. The proper solution is to use one of those. There's no way we can do what's required from inside postgresql, and I see no reason why we should re-invent generic clustering software. (for example, if you do this, we can't prevent the two kernels from corrupting the filesystem on the shared storage, which we rely on working..) Such software is often marketed as an "easy way to set up high availability". It's easy to set up. It requires some actual expertise to set up *right*. But once you've done that, it works well, and it prevents this kind of situation to happen. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers