Re: create tablespace fails silently, or succeeds improperly

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On mn, 2010-10-18 at 15:50 -0400, Tom Lane 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.
>> 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.

Well, it is only an argument by analogy, but the proposal does fix the
IMO-clear misbehavior complained of way back at the start of this
thread.

> 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.

I can't get excited about it. That would break every existing tool that
looks into PGDATA, for a fairly marginal simplification during version
upgrades. To give just one example of the pain we'd be letting
ourselves in for, pg_ctl would now become extremely version-specific.
You couldn't even get away with using the wrong copy of pg_ctl during a
reinstall after a catversion bump during development.

regards, tom lane