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
Re: Table Spaces |
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: