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
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
> 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
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-12-12 23:16:50|
|Subject: Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER
DATABASE SET ROLE|
|Previous:||From: Simon Riggs||Date: 2010-12-12 23:08:43|
|Subject: Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED|