RE: pg_restore issues with intarray

From: Kevin Brannen <KBrannen(at)efji(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: RE: pg_restore issues with intarray
Date: 2019-09-06 15:45:08
Message-ID: DM6PR19MB345141EE667528705B9DCB5CA4BA0@DM6PR19MB3451.namprd19.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
>On 9/5/19 5:05 PM, Kevin Brannen wrote:
>>
>> It feels like the restore is adding the intarray extension, which does
>> a CREATE OPERATOR FAMILY on its own, then later the restore does
>> CREATE OPERATOR FAMILY on again causing the problem. Yet this doesn't
>> happen on most of our databases, just a few. It's maddening to me.
>>
>What does \dx show in the database you taking the dump from?

Sadly, I don't have access to that system.

>What if you do a restore to a file only the schema e.g.:
>
>pg_restore -s -f some_file.sql
>
>This will create a plain text version of only the schema objects in some_file.sql instead of restoring to the database. It might help shed some light.

No CREATE EXTENSION or CREATE OPERATOR FAMILY statements.

Jerry's post indicates this is something that just happens with some older
versions and it seems I got unlucky. I do have a work around (ignore) but
I'd rather be proactive in knowing I'm ignoring something I should be and
not ignoring meaningful errors.

Thanks for the help Adrian, I really appreciate it!
This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, distribution, review, copy or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify us by reply e-mail, and destroy the original transmission and its attachments without reading them or saving them to disk. Thank you.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jerry Sievers 2019-09-06 16:58:35 Re: pg_restore issues with intarray
Previous Message Kevin Brannen 2019-09-06 15:32:17 RE: pg_restore issues with intarray