Re: tablespaces inside $PGDATA considered harmful - Mailing list pgsql-hackers

From Marc Mamin
Subject Re: tablespaces inside $PGDATA considered harmful
Date
Msg-id B6F6FD62F2624C4C9916AC0175D56D8828B59E30@jenmbs01.ad.intershop.net
Whole thread Raw
In response to Re: tablespaces inside $PGDATA considered harmful  (David G Johnston <david.g.johnston@gmail.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.)
Next
From: Andres Freund
Date:
Subject: Re: Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.)