On Wed, Apr 2, 2008 at 10:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Morris Goldstein" <morris.x.goldstein@gmail.com> writes:
>
> > Without going into a lot of details about our application, I'll just
> > say that the ability to start Postgres with just the "startup schema"
> > present is incredibly useful. On a SAN, we put this startup schema
> > on a volume that is permanently bound to a node, and the other schema
> > on a volume that can fail over to another node. Tablespaces allow us
> > to start Postgres and then fail back the volume containing the second
> > schema.
>
> [ retrieves eyebrows from ceiling... ] Have you actually tested this?
> It sounds to me like you are thinking you can reattach the tablespace
> to a different database instance, which is guaranteed not to work.
> You've got to fail over the entire instance as a whole.
No, nothing like that. Node1 has a database. Let's say that pg_data is
on /dev/sda and the database hasa tablespace on /dev/sdb. node1
fails. /dev/sdb is actually a SAN volume, and can fail over to another
node, node2. /dev/sdb2 also has non-postgres data that node2 needs.
When the failover happens, node2 uses the non-postgres data and leaves
the postgres data alone. node1 restarts. Postgres restarts and, as
long as it doesn't refer to the /dev/sdb tablespace, my understanding
is that everything is OK. Eventually, /dev/sdb fails back to node1,
and at that point references to the tablespace on that volume should
work.
(Why not give postgres its own volumes? Long and not very interesting story.)
None of this is implemented -- I'm checking out the issues here as
part of a design task. I'm not using autovacuum, and the only other
issue I've turned up is references to the tablespace on /dev/sdb from
the WAL.
Morris
