pg_upgrade error regarding hstore operator

From: "Feld, Michael (IMS)" <FeldM(at)imsweb(dot)com>
To: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: pg_upgrade error regarding hstore operator
Date: 2016-03-08 18:27:06
Message-ID: 4b5993299ed948728e2ad6e278861807@NAIAD.omni.imsweb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

I am attempting to upgrade my organization's database cluster from 9.1.19 to 9.5.1 using the pg_upgrade utility. After some processing, the tool bails out with the following error in the log:

pg_restore: creating OPERATOR "public.=>"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 5660; 2617 5655672 OPERATOR => postgres
pg_restore: [archiver (db)] could not execute query: ERROR: syntax error at or near "=>"
LINE 1: CREATE OPERATOR => (
^
Command was: CREATE OPERATOR => (
PROCEDURE = "hstore",
LEFTARG = "text",
RIGHTARG = "text"
);

-- For binary upgrade, handle...

I tried dropping the operator before doing the upgrade but it's dependent on the existence of the hstore extension. Ideas?

________________________________

Information in this e-mail may be confidential. It is intended only for the addressee(s) identified above. If you are not the addressee(s), or an employee or agent of the addressee(s), please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender of the error.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2016-03-08 20:03:01 Re: Exclude pg_largeobject form pg_dump
Previous Message Thiemo Kellner, NHC Barhufpflege 2016-03-08 18:10:12 Re: Logger into table and/or to cli

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-03-08 18:38:22 Re: Freeze avoidance of very large table.
Previous Message Shulgin, Oleksandr 2016-03-08 18:25:06 Re: More stable query plans via more predictable column statistics