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