On Sat, Jan 21, 2017 at 9:53 PM, Tom Lane wrote:
> Amitabh Kant writes:
> > command: "/var/tmp/pgbin.SPOsRj4D/bin/pg_ctl" -w -l
> "pg_upgrade_server.log"
> > -D "/usr/local/pgsql/data91" -o "-p 50432 -b -c listen_addresses='' -c
> > unix_socket_permissions=0700 -c unix_socket_directory='/usr/
>
Amitabh Kant writes:
> command: "/var/tmp/pgbin.SPOsRj4D/bin/pg_ctl" -w -l "pg_upgrade_server.log"
> -D "/usr/local/pgsql/data91" -o "-p 50432 -b -c listen_addresses='' -c
> unix_socket_permissions=0700 -c unix_socket_directory='/usr/local/pgsql'"
Note the unix_socket_directory parameter, which
parihaaraka writes:
> I have the same issue after pg_upgrade from 9.3 to 9.5.
> pg_dump generates excess commands like
> CREATE OPERATOR FAMILY bit_ops USING gin;
> ...
> while all of this is done during CREATE EXTENSION
This is fixed in the latest round of minor releases, but not in a way th
Hello, All
I have the same issue after pg_upgrade from 9.3 to 9.5.
pg_dump generates excess commands like
CREATE OPERATOR FAMILY bit_ops USING gin;
...
while all of this is done during CREATE EXTENSION
(i have only btree_gin and plpgsql installed)
--
View this message in context:
http://pos
om text[] to hstore
function akeys(hstore)
function avals(hstore)
function defined(hstore,text)
function delete(hstore,hstore)
function delete(hstore,text)
function delete(hstore,text[])
function each(hstore)
function exist(hstore,text)
function exists_all(hstore,text[])
function exists
"Feld, Michael (IMS)" writes:
> Thanks for the reply Tom. template1 is definitely empty and does not contain
> any hstore objects. I did a little debugging and placed the below SQL before
> and after the hstore creation in the file produced by the pg_dump and
> determined that these operator ob
al Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Wednesday, April 06, 2016 7:01 PM
To: Feld, Michael (IMS)
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] pg_upgrade error regarding hstore operator
"Feld, Michael (IMS)" writes:
> Thanks for the assist Tom. That wo
"Feld, Michael (IMS)" writes:
> Thanks for the assist Tom. That worked for us. Noticing a different
> issue following the pg_upgrade. If we take a pg_dump of a database on
> this upgraded instance with the hstore extension and try to pg_restore
> it back up to the same instance we get the followin
it did not. Thanks for any help you
can offer.
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Tuesday, March 08, 2016 6:22 PM
To: Feld, Michael (IMS)
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] pg_upgrade error regarding hstore operator
"Feld, Michael
"Feld, Michael (IMS)" writes:
> I am attempting to upgrade my organization's database cluster from
> 9.1.19 to 9.5.1 using the pg_upgrade utility.
That's kind of a big jump :-( ... you missed the versions where =>
was deprecated as an operator name.
> I tried dropping the operator before doing t
On 03/08/2016 10:27 AM, Feld, Michael (IMS) wrote:
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_restor
On Thu, May 9, 2013 at 06:16:31PM +0530, Ramesh naik wrote:
> hello there,
>
> we are getting struck with this error while upgrading while upgrading from 9.1
> to 9.2
>
>
> -bash-4.1$ clear
> -bash-4.1$ /usr/pgsql-9.2/bin/pg_upgrade -c --old-datadir=/var/lib/pgsql/9.1/
> data --new-datadir=/va
12 matches
Mail list logo
