Re: tablespaces inside $PGDATA considered harmful
Re: tablespaces inside $PGDATA considered harmful
От:
David G Johnston <david.g.johnston@gmail.com>
Дата:
Re: tablespaces inside $PGDATA considered harmful
От:
Bruce Momjian <bruce@momjian.us>
Дата:
On Fri, Jan 30, 2015 at 01:26:22PM -0800, Josh Berkus wrote: > Robert, Stephen, etc.: > > Apparently you can create a tablespace in the tablespace directory: > > josh=# create tablespace tbl location '/home/josh/pg94/data/pg_tblspc/'; > CREATE TABLESPACE > josh=# create table test_tbl ( test text ) tablespace tbl; > CREATE TABLE > josh=# \q > josh@Radegast:~/pg94/data/pg_tblspc$ ls > 17656 PG_9.4_201409291 > josh@Radegast:~/pg94/data/pg_tblspc$ ls -l > total 4 > lrwxrwxrwx 1 josh josh 30 Jan 30 13:02 17656 -> > /home/josh/pg94/data/pg_tblspc > drwx------ 3 josh josh 4096 Jan 30 13:02 PG_9.4_201409291 > josh@Radegast:~/pg94/data/pg_tblspc$ > > In theory if I could guess the next OID, I could cause a failure there, > but that appears to be obscure enough to be not worth bothering about. > > What is a real problem is that we don't block creating tablespaces > anywhere at all, including in obviously problematic places like the > transaction log directory: > > josh=# create tablespace tbl2 location '/home/josh/pg94/data/pg_xlog/'; > CREATE TABLESPACE > > It really seems like we ought to block *THAT*. Of course, if we block > tablespace creation in PGDATA generally, then that's covered. I have developed the attached patch to warn about creating tablespaces inside the data directory. The case this doesn't catch is referencing a symbolic link that points to the same directory. We can't make it an error so people can use pg_upgrade these setups. This would be for 9.5 only. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Re: [HACKERS] tablespaces inside $PGDATA considered harmful
От:
Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
Дата:
On 26/09/17 20:44, Mark Kirkwood wrote: > > > $ 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 "." > Err - actually this example is wrong - sorry. In fact pg_basebackup is complaining because it does not want to overwrite the contents of the tablespace (need to use the -T option as I'm on the same host)! A correct example of pg_basebackup failing due to tablespaces inside $PGDATA/pg_tblspc can be easily demonstrated by trying to set up streaming replication on another host: $ pg_basebackup -h 10.0.119.100 -P -D . WARNING: could not read symbolic link "pg_tblspc/space1": Invalid argument pg_basebackup: could not create directory "./pg_tblspc": File exists Fortunately this can be worked around by changing to tar format: $ pg_basebackup -h 10.0.119.100 -Ft -P -D . WARNING: could not read symbolic link "pg_tblspc/space1": Invalid argument 1560632/1560632 kB (100%), 2/2 tablespaces ...however, not that great that the plain mode is busted. 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
Re: [HACKERS] tablespaces inside $PGDATA considered harmful
От:
Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
Дата:
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
