From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | James Sewell <james(dot)sewell(at)jirotech(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 00:03:30 |
Message-ID: | e1602016-3c54-f4cb-7b33-a28fec5210f5@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Ron | 2019-09-04 00:19:49 | Re: killing vacuum analyze process |
Previous Message | Will Storey | 2019-09-03 23:38:19 | Re: Unexpected "canceling statement due to user request" error |