Re: create tablespace fails silently, or succeeds improperly

On Fri, Dec 10, 2010 at 3:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm finally getting around to something that's been on my todo list for
> a couple of months.
>
> 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.
>> 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.
>
>> Barring objections, I'll go make it work that way in HEAD and 9.0.
>
> Looking at initdb, there's a couple of hundred lines worth of code
> involved here.  Some of it is not directly sharable with the backend
> because of the way it manages error cases, but at least the two
> functions mkdir_p() and check_data_dir() could conceivably be put
> into src/port/.  The former is about 100 lines and the latter about 50.
> Is sharing them worth doing, or should I just copy-and-paste into
> commands/tablespace.c?  If we're not sharing mkdir_p in toto, I'd be
> inclined to not bother with duplicating initdb's willingness to create
> parent directories --- it's not clear to me that that's very sensible
> for a tablespace creation command anyway.

+1 for src/port.

> Another question is whether we're really hot enough about this to
> back-patch the change into 9.0.  Given the lack of other complaints
> since October, maybe we shouldn't take any risk here.  Messing around
> with new modules in src/port/ would be more appetizing if it's HEAD
> only.
>
> Thoughts?

At the moment, I'm not feeling hot to back-patch this.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company