Re: create tablespace fails silently, or succeeds improperly - Mailing list pgsql-hackers

From Tom Lane
Subject Re: create tablespace fails silently, or succeeds improperly
Date
Msg-id 28764.1292012801@sss.pgh.pa.us
Whole thread Raw
In response to Re: create tablespace fails silently, or succeeds improperly  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: create tablespace fails silently, or succeeds improperly  (Robert Haas <robertmhaas@gmail.com>)
Re: create tablespace fails silently, or succeeds improperly  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.

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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: ALTER EXTENSION ... UPGRADE;
Next
From: Andrew Dunstan
Date:
Subject: Re: SQL/MED - file_fdw