Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On 29/04/15 09:35, Bruce Momjian wrote:

> On Fri, Apr 24, 2015 at 01:05:03PM -0400, Bruce Momjian wrote:
>> This way, both pg_dump and pg_upgrade will issue warnings, though, of
>> course, those warnings can be ignored.  I am hopeful these two warnings
>> will be sufficient and we will not need make these errors, with the
>> possible inconvenience it will cause.  I am still afraid that someone
>> will ignore the new errors pg_dump would generate and lose data.  I just
>> don't remember enough cases where we threw new errors on _data_ restore.
>>
>> Frankly, those using pg_upgrade already will have to move the old
>> tablespaces out of the old cluster if they ever want to delete those
>> clusters, so I am hopeful these additional warnings will help eliminate
>> this practice, which is already cumbersome and useless.  I am not
>> planning to revisit this for 9.6.
>

(resurrecting an old thread) I encountered this the other day, a 
customer had created tablespaces with directories inside 
$PGDATA/pg_tblspc. This is just pathalogical - e.g (v11 checkout with 
PGDATA=/data0/pgdata/11):

bench=# CREATE TABLESPACE space1 LOCATION 
'/data0/pgdata/11/pg_tblspc/space1';
WARNING:  tablespace location should not be inside the data directory
CREATE TABLESPACE
bench=# ALTER TABLE pgbench_accounts SET  TABLESPACE space1;
ALTER TABLE

Ok, so I've been warned:

$ pg_basebackup -D .
WARNING:  could not read symbolic link "pg_tblspc/space1": Invalid argument
pg_basebackup: directory "/data0/pgdata/11/pg_tblspc/space1" exists but 
is not empty
pg_basebackup: removing contents of data directory "."

So pg_basebackup is completely broken by this construction - should we 
not prohibit the creation of tablespace directories under $PGDATA (or at 
least $PGDATA/pg_tblspc) at this point?

regards

Mark




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers