Re: Upgrade 96 -> 11 - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Upgrade 96 -> 11
Date
Msg-id 5fcbcde1-8807-17ee-029f-c99f924e024e@aklaver.com
Whole thread Raw
In response to Upgrade 96 -> 11  (James Sewell <james.sewell@jirotech.com>)
List 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.klaver@aklaver.com



pgsql-general by date:

Previous
From: Luca Ferrari
Date:
Subject: partition by range or by list constraint check (was Re: literal vsdynamic partition constraint in plan execution)
Next
From: Tom Lane
Date:
Subject: Re: partition by range or by list constraint check (was Re: literal vs dynamic partition constraint in plan execution)