On mån, 2010-10-18 at 15:50 -0400, Tom Lane wrote: > Yeah. We have gotten complaints in the past from people who tried to > specify a mount point as a tablespace, and it failed because of > lost+found or the mount dir being root-owned. We've told them to make > a subdirectory, but that always seemed like a workaround. With the > new layout there's no longer any strong reason to prevent this case > from working. > > 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. > We have more than ten years experience behind the assertion that we're > dealing with that case in a good way. We should transfer that > behavior over to tablespace directories rather than inventing > something that works a shade differently.
I'm still struggling with the above argument. In one case you are applying a behavior to the argument given to initdb, in the other case you are applying the behavior to a subdirectory of the argument given to CREATE TABLESPACE. I'm not saying the solution is necessarily wrong, but it doesn't seem that this will make things easier or more consistent. An idle thought: How about creating a version-subdirectory also in the PGDATA path. The point about mountpoint annoyance applies here just as well. And it could also make the directory juggling during in-place upgrade more normalized and robust. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
