Re: Upgrade 96 -> 11

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: James Sewell <james(dot)sewell(at)jirotech(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Upgrade 96 -> 11
Date: 2019-09-02 13:56:49
Message-ID: 5fcbcde1-8807-17ee-029f-c99f924e024e@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 9/1/19 9:03 PM, James Sewell wrote:
> Hi,
>
> I'm in the process of upgrading from 96 -> 11 (on RHEL 7.3) . Both the
> versions have PostGIS 2.5.1 installed and working.
>
> pg_upgrade fails with:
>
> pg_restore: [archiver (db)] Error from TOC entry 440; 1259 537086 TABLE
> tablename databasename
> pg_restore: [archiver (db)] could not execute query: ERROR:  relation
> "public.spatial_ref_sys" does not exist
> LINE 39:     "location_pt" "public"."geography"(Point,4283),
>

You used the 11 version of pg_upgrade, correct?

> On looking further at the sequence of events I can see that:
>
> 1. The PostGIS extension is created (but somehow the related tables
> such as spatial_ref_sys do not get created)
> 2. The tablename table gets created causing the above error
> 3. At some point later in the upgrade spatial_ref_sys is to be created

Questions:

1) How was PostGIS installed on the 9.6.? and 11.? versions?
Where extensions used or was the manual method used?

2) Did you end up with a working install in 11.?

>
>
> Is there any way round this type of issue (I guess forcing
> spatial_ref_sys to be created either with the extension as normal or
> just before any tables which rely on it).
>
> Cheers,
> James Sewell,
>
>
> ------------------------------------------------------------------------
> The contents of this email are confidential and may be subject to legal
> or professional privilege and copyright. No representation is made that
> this email is free of viruses or other defects. If you have received
> this communication in error, you may not copy or distribute any part of
> it or otherwise disclose its contents to anyone. Please advise the
> sender of your incorrect receipt of this correspondence.

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2019-09-02 15:32:22 Re: partition by range or by list constraint check (was Re: literal vs dynamic partition constraint in plan execution)
Previous Message Luca Ferrari 2019-09-02 08:40:37 partition by range or by list constraint check (was Re: literal vs dynamic partition constraint in plan execution)