Re: pg_upgrade: delete_old_cluster.sh issues
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade: delete_old_cluster.sh issues |
Дата | |
Msg-id | 20140308034656.GG16324@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade: delete_old_cluster.sh issues (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On Mon, Nov 18, 2013 at 10:13:19PM -0500, Bruce Momjian wrote: > On Tue, Nov 12, 2013 at 10:35:58AM +0000, Marc Mamin wrote: > > Hello, > > > > IMHO, there is a serious issue in the script to clean the old data directory > > when running pg_upgrade in link mode. > > > > in short: When working with symbolic links, the first step in > > delete_old_cluster.sh > > is to delete the old $PGDATA folder that may contain tablespaces used by the > > new instance. > > > > in long, our use case: > > Rather than removing files/directories individually, which would be > difficult to maintain, we decided in pg_upgrade 9.3 to detect > tablespaces in the old data directory and report that and not create a > delete script. Here is the commit: > > http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=4765dd79219b9697d84f5c2c70f3fe00455609a1 > > The problem with your setup is that while you didn't pass symbolic links > to pg_upgrade, you did use symbolic links when defining the tablespaces, > so pg_upgrade couldn't recognize that the symbolic links were inside the > old data directory. > > We could use readlink() to go walk over all symbolic links, but that > seems quite complex. We could use stat() and make sure there are no > matching inodes in the old data directory, or that they are in a > different file system. We could look for a directory named after the PG > catversion in the old data directory. We could update the docs. > > I am not sure what to do. We never expected people would put > tablespaces in the data directory. I went with a doc patch, attached. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Вложения
В списке pgsql-hackers по дате отправления: