I assume CREATE TABLESPACE refuses to use a non-empty directory because of the
risk of trashing existing files. Makes sense, but consider the following:
# mkfs -t ext2 /dev/sdc1
# mount -t ext2 /dev/sdc1 /mnt/pg_tables
# chown postgres /mnt/pg_tables
# su -c psql pyarra
pyarra=# CREATE TABLESPACE spc_tables LOCATION '/mnt/pg_tables/';
ERROR: directory "/mnt/pg_tables" is not empty
This is because lost+found exists. Since lost+found would be a reasonably
common directory to find at a mount-point on Unix-like OSs*, would it make
sense for CREATE TABLESPACE to ignore it if present?
Of course this isn't hard to get around:
# mkdir /mnt/pg_tables/data
# chown postgres /mnt/pg_tables/data
CREATE TABLESPACE spc_tables LOCATION '/mnt/pg_tables/data/';
If consensus is that it is a bad idea to treat lost+found as a special case,
would it be worth putting an explicit mention in the doco about the preferred
way to set up a database with multiple disks?
Related question: are there plans afoot to allow specifying an alternate
location for pg_xlog (or pg_delete-me-not) to save doing the shutdown-DB, mv
directory to other disk, symlink, start-DB dance?
Regards, Philip.
* Solaris 9 and Linux both use lost+found, Tru64 v4.0f does not seem to (and
has extra guff for quota management too). I doubt we could cater to every
possible Unix OS and the administrative files it creates at mount points,
however since lost+found is so common, if it's there, we could ignore it.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-----------------
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.
