On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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?
Seems a bit surprising. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
