> 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.
Yes, this is the reason why we got in this issue. The name PGDATA is misleading.
> 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.
true too. We have a lot of tablespaces. I'd probably won't go that way by now, but it still has the advantage to help
quicklymove parts of the data to manage filesystem usage.
> Given all this, it seems like a good idea to at least give a warning
> if somebody tries to create a tablespace instead the data directory.
IMHO the first place to put a warning is within the
documentation:http://www.postgresql.org/docs/9.4/interactive/manage-ag-tablespaces.htmlandpossibly a crosslink in
http://www.postgresql.org/docs/9.4/interactive/sql-createtablespace.html
>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.
We have a lot of maintenance scripts that rely on our architecture
($PGDADAT -> symlinks -> tablespace locations).
We already made a quick evaluation on how to fix this, but gave it up
for now due to the work amount.
So please be cautious about disallowing it too abruptly.
Back-patching a change that disallow our current architecture could prevent us
to apply minor releases for a while...
regards,
Marc Mamin