Re: Alternative database locations are broken

Peter Eisentraut <peter_e@gmx.net> writes:
> But RelFileNode already claims to store the identity of the table space,
> being the database oid.  This doesn't work because a location can contain
> more than one database.  So effectively we'd need to redefine RelFileNode
> something like 'struct { locationid, dbid, relid }'.

No, I don't think so.  The direction we want to head in is that RelFileNode
should identify a tablespace (physical storage location) and a table.
There isn't any need for a hardwired association between tablespaces and
databases, at least not at this level.

IIRC, the proposed design that Vadim was basing this on is that the
actual path to a particular file would be$PGDATA/base/TABLESPACE/TABLE
or for a segmented relation$PGDATA/base/TABLESPACE/TABLE.SEGMENT
where TABLESPACE, TABLE, and SEGMENT are all numeric strings --- the
first two come from RelFileNode and the last from the target block #.

In this design, the tablespace directories appearing under $PGDATA/base
can either be plain subdirectories, or symlinks to directories that live
elsewhere.  The low-level file access code doesn't know or care which.

The questions you are asking seem to concern design of a user interface
that lets these directories or symlinks get set up via SQL commands
rather than direct manual intervention.  I agree that's a good thing to
have, but it's completely separate from the low-level access code.

The current implementation has one physical-subdirectory tablespace per
database, but I don't see any reason that multiple databases couldn't
share a tablespace, or that tables in a database couldn't be scattered
across multiple tablespaces.  We just need to design the commands that
let the dbadmin control this.

BTW, we could eliminate special-casing for the shared system relations
if we treat them as stored in another tablespace.  For example, make
$PGDATA/base/0 be a symlink to ../global, or just move the stuff
currently in $PGDATA/global to a subdirectory of $PGDATA/base.

>> I think that to handle locations we could symlink catalogs - ln -s
>> path_to_database_in_some_location .../base/DatabaseOid

> But that's a kludge.  We ought to discourage people from messing with the
> storage internals.

It's not a kluge, it's a perfectly fine implementation.  The only kluge
here is if people have to reach in and establish such symlinks by hand.
We want to set up a user interface that hides the implementation.
        regards, tom lane