Re: pg_upgrade: delete_old_cluster.sh issues

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Marc Mamin <M(dot)Mamin(at)intershop(dot)de>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade: delete_old_cluster.sh issues
Date: 2013-11-19 03:13:19
Message-ID: 20131119031319.GH28149@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-11-19 03:15:50 Re: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Previous Message Peter Geoghegan 2013-11-19 03:03:00 Re: Improvement of pg_stat_statement usage about buffer hit ratio