Re: [GENERAL] pg_upgrade & tablespaces

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Joseph Kregloh <jkregloh(at)sproutloud(dot)com>, John R Pierce <pierce(at)hogranch(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] pg_upgrade & tablespaces
Date: 2014-04-17 15:44:42
Message-ID: 20140417154442.GE7443@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wed, Apr 16, 2014 at 01:49:20PM -0400, Bruce Momjian wrote:
> On Sun, Jan 12, 2014 at 11:04:41PM -0500, Bruce Momjian wrote:
> > > In the pgsql_old installation you have symlinks pointing back to the
> > > current default location. As well pg_tablespace points back to
> > > /usr/local/pgsql/data/ The issue is that there is not actually
> > > anything there in the way of a tablespace. So when pg_upgrade runs
> > > it tries to upgrade from /usr/local/pgsql/data/tblspc_dir to
> > > /usr/local/pgsql/data/tblspc_dir where the first directory either
> > > does not exist. or if the user went ahead and created the directory
> > > in the new installation, is empty. What is really wanted is to
> > > upgrade from /usr/local/pgsql_old/data/tblspc_dir to
> > > /usr/local/pgsql/data/tblspc_dir. Right now the only way that
> > > happens is with user intervention.
> >
> > Right, it points to _nothing_ in the _new_ cluster. Perhaps the
> > simplest approach would be to check all the pg_tablespace locations to
> > see if they point at real directories. If not, we would have to have
> > the user update pg_tablespace and the symlinks. :-( Actually, even in
> > 9.2+, those symlinks are going to point at the same "nothing". That
> > would support checking the symlinks in all versions.
>
> I have developed the attached patch which checks all tablespaces to make
> sure the directories exist. I plan to backpatch this.
>
> The reason we haven't seen this bug reported more frequently is that a
> _database_ defined in a non-existent tablespace directory already throws
> an backend error, so this check is only necessary where tables/indexes
> (not databases) are defined in non-existant tablespace directories.

Patch applied and backpatched to 9.3. I beefed up the C comment to
explain how this can happen:

Check that the tablespace path exists and is a directory.
Effectively, this is checking only for tables/indexes in
non-existent tablespace directories. Databases located
in non-existent tablespaces already throw a backend error.
Non-existent tablespace directories can occur when a data directory
that contains user tablespaces is moved as part of pg_upgrade
preparation and the symbolic links are not updated.

Thanks for the report and debugging.

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

+ Everyone has their own god. +

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2014-04-17 15:45:42 Re: pg_upgrade & tablespaces
Previous Message Robert DiFalco 2014-04-17 15:41:26 Re: Re: any way for a transaction to "see" inserts done earlier in the transaction?

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-04-17 15:45:42 Re: pg_upgrade & tablespaces
Previous Message Tom Lane 2014-04-17 15:44:37 Re: Verbose output of pg_dump not show schema name