I wrote:
>> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
>> the creation and properties of /foo/bar/PG_9.0_201004261 ought to be
>> handled *exactly* the way that the -D target directory of initdb is.
One interesting point here is that initdb uses the equivalent of mkdir
-p, so it will automatically try to create parent directories of
whatever path you specify. Duplicating that behavior in CREATE
TABLESPACE causes this diff in the regression tests:
-- Will fail with bad path
CREATE TABLESPACE badspace LOCATION '/no/such/location';
! ERROR: directory "/no/such/location" does not exist
-- No such tablespace
CREATE TABLE bar (i int) TABLESPACE nosuchspace;
ERROR: tablespace "nosuchspace" does not exist
--- 65,71 ----
-- Will fail with bad path
CREATE TABLESPACE badspace LOCATION '/no/such/location';
! ERROR: could not create directory "/no": Permission denied
-- No such tablespace
CREATE TABLE bar (i int) TABLESPACE nosuchspace;
ERROR: tablespace "nosuchspace" does not exist
I'm not sure that this is a bad thing. In particular, it makes WAL
replay noticeably more robust since it will do what it can to regenerate
the whole path if you deleted parent directories. It will of course
still fail, as here, if the server doesn't have write permissions on the
last existing dir in the path.
Anybody have a problem with adopting this behavior?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
