Re: create tablespace fails silently, or succeeds improperly

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-12 23:10:41
Message-ID: 11736.1292195441@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-12-12 23:16:50 Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE
Previous Message Simon Riggs 2010-12-12 23:08:43 Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED