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.
