Re: pg_upgrade: delete_old_cluster.sh issues - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade: delete_old_cluster.sh issues
Date
Msg-id 20131119031319.GH28149@momjian.us
Whole thread Raw
In response to pg_upgrade: delete_old_cluster.sh issues  (Marc Mamin <M.Mamin@intershop.de>)
Responses Re: pg_upgrade: delete_old_cluster.sh issues  (Bruce Momjian <bruce@momjian.us>)
List 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: GIN improvements part2: fast scan
Next
From: Bruce Momjian
Date:
Subject: Re: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block