Table Spaces - Mailing list pgsql-hackers

From Gavin Sherry
Subject Table Spaces
Date
Msg-id Pine.LNX.4.58.0405172007100.14604@linuxworld.com.au
Whole thread Raw
In response to Re: add server include files to default installation?  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Table Spaces  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Table Spaces  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
List pgsql-hackers
Hi all,

Attached is a patch against HEAD implementing tablespaces.

I've done some testing on Linux and BSD. I've also compiled without
HAVE_SYMLINK defined -- which determines whether or not tablespaces are
available.

The reason for this is that symlinks are used extensively to simplify
access to relations in hairy places.

This is extensive discussion of this in the archives.

There are some outstanding TODOs. These include

pg_dump
documentation
regression tests
comment on

Chris KL has offered to tackle these.

Other outstanding things which need to be resolved:

XLog entries:

Within a tablespace, the files for different databases are isolated into
directories. Those directory names are the database oid for those files.
Since we create those files, we should log them. The question is, what is
the best way: appending it to an xlrec and storing its length in the xlrec
or adding another rdata with that in it?

The same goes for symlinks, where we need to store the oldpath and
newpath.

Alternative database location:

Should this code be removed now?

Drop tablespace:

I haven't added an interlock here (as suggested by Tom) to handle
situations where one transaction schedules the removal of a tablespace and
concurrently another transaction makes use of that tablespace. I'd
appreciate some advice on what this would look like: should a command
creating an object touch a CREATE a file and a DROP TABLESPACE block until
the file goes away, then check if it can drop the tablespace (ie, that the
tablespace is empty)? Likewise when DROP TABLESPACE proceeds, should it
block creates?

The other thing is handling DROP TABLESPACE in a transaction where the
tablespace has been emptied (using DROP TABLE, etc) during that
transaction. Because we only schedule the unlink() of the relation, the
data files will (and must) still be around. Is it reasonable to look
inside PendingRelDeletes to see if the tablespace will be empty at COMMIT?

Basic usage rundown

initdb sets up a new directory pg_tablespaces with some symlinks with in
it. To create a tablespace, you must first up create a tablespace
directory. Then you can create a tablespace inside postgres using:

CREATE TABLESPACE <name> LOCATION '/path/to/tbl/dir'

Then, the DDL commands can have a tablespace associatged with it:

CREATE DATABASE ... TABLESPACE <name>
CREATE SCHEMA ... TABLESPACE <name>
CREATE TABLE ... TABLESPACE <name>
CREATE INDEX ... TABLESPACE <name>
CREATE SEQUENCE ... TABLESPACE <name>

Comments, criticisms, etc, all welcome, of course.

Thanks,

Gavin

pgsql-hackers by date:

Previous
From: Tommi Maekitalo
Date:
Subject: Re: email data type first release
Next
From: "Andrew Dunstan"
Date:
Subject: Re: enabling tcpip_socket by default