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

Re: create tablespace fails silently, or succeeds improperly

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 22:04:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On mån, 2010-10-18 at 15:50 -0400, Tom Lane wrote:
> Yeah.  We have gotten complaints in the past from people who tried to
> specify a mount point as a tablespace, and it failed because of
> lost+found or the mount dir being root-owned.  We've told them to make
> a subdirectory, but that always seemed like a workaround.  With the
> new layout there's no longer any strong reason to prevent this case
> from working.
> 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

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.

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2010-12-12 22:12:40
Subject: Re: Per-column collation
Previous:From: Alexander KorotkovDate: 2010-12-12 21:53:26
Subject: Re: Wildcard search support for pg_trgm

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