> 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 quickly move 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.html and possibly 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
