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