Re: tablespaces inside $PGDATA considered harmful

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

In response to

Browse pgsql-hackers by date

  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.)