From: David G Johnston <david.g.johnston@gmail.com>
To: pgsql-hackers@postgresql.org
Subject: Re: tablespaces inside $PGDATA considered harmful
Date: Fri, 30 Jan 2015 10:35:52 -0700 (MST)
Message-ID: <1422639352066-5836180.post@n5.nabble.com> (raw)
In-Reply-To: <CA+TgmobZLyLU8tFCbMqbjMWB6t+=ERaDo820uQEJCVAQK_Paow@mail.gmail.com>
References: <CA+TgmobZLyLU8tFCbMqbjMWB6t+=ERaDo820uQEJCVAQK_Paow@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Robert Haas wrote
> Arguably, we should prohibit it altogether, but there are obviously
> people that want to do it, and there could even be somewhat valid
> reasons for that,
Lots of hand-waving here and it is just as likely they simply are not aware
of the downsides and the only reason they put it is $PGDATA is that
it seemed like a logical place to put a directory that is intended to hold
database data.
> like wanting to set per-tablespace settings differently for different
> tablespaces.
I do not follow where this has anything to do with the location of the
physical tablespace directory?
> Possibly we should prohibit it
> anyway, or maybe there should be an option to create a tablespace
> whose directory is a real directory, not a symlink. So then:
>
> CREATE TABLESPACE foo LOCATION '/home/rhaas/pgdata/pg_tblspc/foo';
>
> ...would fail, but if you really want a separate tablespace inside the
> data directory, we could allow:
>
> CREATE TABLESPACE foo NO LOCATION;
>
> ...which would just create a bare directory where the symlink would
> normally go.
CREATE TABLE foo LOCATION INTERNAL
The creators of tablespaces seem to have envisioned their usage as a means
of pulling in
disparate file systems and not simply for namespaces within the main
filesystem
that $PGDATA exists on.
This seems arbitrary and while the internal location specification likely
doesn't buy one much in terms of real options it doesn't seem like it has
any serious downsides either.
> In the short term, I favor just adding a warning, so that people get
> some clue that they are doing something that might be a bad idea. In
> the long term, we might want to do more. Thoughts?
If this is intended to be back-patched then I'd go with just a warning. If
this is strictly 9.5 material then I'd say that since our own tools behave
badly in the current situation we should simply outright disallow it. In
either case we should consider what tools we can provide to detect the
now-illegal configuration and, during pg_upgrade, configure the new cluster
to adhere to the correct configuration or help the user migrate their
internalized tablespaces to a different part of their filesystem.
Writing this I ponder the situation that someone would mount a different
file system directly under $PGDATA so that they get both benefits - single
parent and the different properties of the filesystems they are using. If
we force "Internal" to be in the same location as the default tablespace we
only accomplish half of their goals.
David J.
--
View this message in context: http://postgresql.nabble.com/tablespaces-inside-PGDATA-considered-harmful-tp5836161p5836180.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: david.g.johnston@gmail.com
Subject: Re: tablespaces inside $PGDATA considered harmful
In-Reply-To: <1422639352066-5836180.post@n5.nabble.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox