Re: [GENERAL] pg_upgrade & tablespaces - Mailing list pgsql-hackers

From Adrian Klaver
Subject Re: [GENERAL] pg_upgrade & tablespaces
Date
Msg-id 52D3647C.1050704@gmail.com
Whole thread Raw
In response to Re: [GENERAL] pg_upgrade & tablespaces  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [GENERAL] pg_upgrade & tablespaces  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 01/12/2014 07:02 PM, Bruce Momjian wrote:
> On Sun, Jan 12, 2014 at 12:48:40PM -0500, Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> On Sat, Jan 11, 2014 at 12:48:51PM -0800, Adrian Klaver wrote:
>>>> I see, though I have another question. If pg_tablespace and the
>>>> symlinks can get out of sync, as you say below, why is pg_tablespace
>>>> considered the authority? Or to put it another way, why not just
>>>> look at the symlinks as in 9.2+?
>>
>>> Uh, good question.  I think I used the system tables because they were
>>> easier to access.  I can't remember if we used the symlinks for some
>>> things and pg_tablespace for other things in pre-9.2.
>>
>> Well, pre-9.2 pg_dumpall is going to make use of the pg_tablespace
>> entries, because it has no other choice.  We could conceivably teach
>> pg_upgrade to look at the symlinks for itself, but we're not going
>> to do that in pg_dumpall.  Which means that the intermediate dump
>> script would contain inconsistent location values anyway if the
>> catalog entries are wrong.  So I don't see any value in changing the
>> quoted code in pg_upgrade.
>
> OK, agreed.
>
>> It does however seem reasonable for pg_upgrade to note whether any
>> of the paths are prefixed by old PGDATA and warn about the risks
>> involved.
>
> Uh, the problem is that once you rename the old PGDATA, the
> pg_tablespace contents no longer point to the current PGDATA.  The
> symlinks, if they used absolute paths, wouldn't point to the current
> PGDATA either.
>

Well the problem is that it actually points to a current PGDATA just the 
wrong one. To use the source installation path and the suggested upgrade 
method from pg_upgrade.

Start.

/usr/local/pgsql/data/tblspc_dir

mv above to

/usr/local/pgsql_old/

install new version of Postgres to

/usr/local/pgsql/data/


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.

-- 
Adrian Klaver
adrian.klaver@gmail.com



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re:
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] pg_upgrade & tablespaces