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.
