Re: Upgrade 96 -> 11

From: James Sewell <james(dot)sewell(at)jirotech(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Upgrade 96 -> 11
Date: 2019-09-04 06:18:51
Message-ID: CAANVwEtXC8yRFqpA3AMYQmiue0mT9GEr7jmJW-_biJg_q+XTWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

If anyone hits this it is an issue with using the Geography type with a non
4326 SRID on a table and pg_upgrade.

It should be fixed (the check dropped as it's something of a relic) in the
next version of PostGIS. In the meantime you would have to patch it out
yourself.

(
https://github.com/postgis/postgis/blob/svn-trunk/postgis/gserialized_typmod.c#L296
)

On Wed, 4 Sep 2019 at 10:03, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 9/3/19 3:45 PM, James Sewell wrote:
> >
> >
>
> >
> > -- For binary upgrade, create an empty extension and insert objects
> > into it
> > DROP EXTENSION IF EXISTS tablefunc;
> > SELECT pg_catalog.binary_upgrade_create_empty_extension('tablefunc',
> > 'public', true, '1.0', NULL, NULL, ARRAY[]::pg_catalog.text[]);
> >
> >
> > Try the above on your schema and see what you get.
> >
> >
> > Yep - an empty extension. I think this logic is wrong. Creating an empty
> > extension is fine and makes sense but extension owned relations should
> > be created as the next step, not just at some time later.
> >
>
> So to be clear you ran pg_dump with --binary-upgrade and the extension
> elements where created after the user table that tripped the error?
>
>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>

--
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.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Arnaud L. 2019-09-04 07:04:33 Re: Slow statement using parallelism after 9.6>11 upgrade
Previous Message Tom Lane 2019-09-04 03:56:35 Re: killing vacuum analyze process