From: | Marc Mamin <M(dot)Mamin(at)intershop(dot)de> |
---|---|
To: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tablespaces inside $PGDATA considered harmful |
Date: | 2015-01-31 11:03:15 |
Message-ID: | B6F6FD62F2624C4C9916AC0175D56D8828B59E30@jenmbs01.ad.intershop.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-01-31 11:11:18 | Re: Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.) |
Previous Message | Andres Freund | 2015-01-31 10:56:37 | Re: Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.) |