Skip site navigation (1) Skip section navigation (2)

Re: create tablespace fails silently, or succeeds improperly

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Dave Cramer <pg(at)fastcrypt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: create tablespace fails silently, or succeeds improperly
Date: 2010-12-10 22:54:23
Message-ID: AANLkTinT=SqJqFp3NGn0jR408H_2SBm8Xp5poOEYGMGY@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Dec 10, 2010 at 3:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-12-10 22:55:43
Subject: Re: ALTER EXTENSION ... UPGRADE;
Previous:From: David E. WheelerDate: 2010-12-10 22:50:09
Subject: Re: ALTER EXTENSION ... UPGRADE;

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group