Re: tablespaces inside $PGDATA considered harmful
От | David Steele |
---|---|
Тема | Re: tablespaces inside $PGDATA considered harmful |
Дата | |
Msg-id | 54CBBB61.1090207@pgmasters.net обсуждение исходный текст |
Ответ на | Re: tablespaces inside $PGDATA considered harmful ("Joshua D. Drake" <jd@commandprompt.com>) |
Список | pgsql-hackers |
On 1/30/15 11:43 AM, Joshua D. Drake wrote: > On 01/30/2015 08:19 AM, Bruce Momjian wrote: >> >> On Fri, Jan 30, 2015 at 11:12:43AM -0500, Robert Haas wrote: >>> I think everyone who has read this mailing list for a while is >>> probably already aware of this problem. When you create a tablespace >>> somewhere inside the data directory, weird things happen. If you >>> pg_upgrade and then incautiously run the delete_old_cluster.sh script >>> thus created, you will blow away large chunks of your data.[1] If you >> >> pg_upgrade doesn't create the deletion script in this case, and warns >> the user: >> >> Could not create a script to delete the old cluster's data >> files because user-defined tablespaces exist in the old cluster >> directory. The old cluster's contents must be deleted >> manually. >> >>> In the short term, I favor just adding a warning, so that people get >>> some clue that they are doing something that might be a bad idea. In >>> the long term, we might want to do more. Thoughts? >> >> Yes, good idea. > > Uhm, wouldn't it be a rather simple patch to say: > > if tablespace_create() in $PGDATA: > ERROR! > > ? > > I mean yes a warning is good but it is after the fact, the tablespace > is already created. We know that tablespaces in $PGDATA are a bad > idea, why not protect the user? I would be in favor of an error. It would then be OK for basebackup, pg_upgrade, and friends to error when a tablespace lives in $PGDATA, rather than trying to deal with the situation in strange ways. If the user really wants tablespaces in $PGDATA they can always change the links manually in the filesystem and deal with any consequences on their own. -- - David Steele david@pgmasters.net
В списке pgsql-hackers по дате отправления: