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-03 19:47:35 |
Message-ID: | e06c290c-d6a3-73f6-4740-cc0260c79433@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 9/2/19 5:52 PM, Adrian Klaver wrote:
>> It's still creating the schema elements when it fails, it hasn't
>> started linking yet
>
> Alright at least you still a working 9.6 cluster .
>
> Not sure where to go from here. Like you I am not sure how it can CREATE
> EXTENSION and not actually follow through on that. Especially with no
> errors for that operation. I'm going to have to think on this. Hopefully
> someone else has an idea on this and can chime in.
Aah. I don't have postgis installed, still:
pg_dump --binary-upgrade -s -d production -U postgres >
production_binary.sql
-- 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.
>
>>
>> >
>> > I have set PGBINOLD, PGBINNEW, PGDATAOLD, PGDATANEW correctly.
>>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Kumar, Virendra | 2019-09-03 20:56:28 | Running a Simple Update Statement Fails, Second Time Suceeds. |
Previous Message | Michael Lewis | 2019-09-03 19:00:39 | Re: literal vs dynamic partition constraint in plan execution |