Re: tablespaces inside $PGDATA considered harmful
От | Marc Mamin |
---|---|
Тема | Re: tablespaces inside $PGDATA considered harmful |
Дата | |
Msg-id | B6F6FD62F2624C4C9916AC0175D56D8828B59E30@jenmbs01.ad.intershop.net обсуждение исходный текст |
Ответ на | Re: tablespaces inside $PGDATA considered harmful (David G Johnston <david.g.johnston@gmail.com>) |
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: