Re: SIGSEGV taken on 8.1 during dump/reload

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Creager <Robert_Creager(at)LogicalChaos(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SIGSEGV taken on 8.1 during dump/reload
Date: 2005-11-09 14:56:51
Message-ID: 43720E33.8010306@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Creager wrote:

>Yup. You're right. So, what is happening here? It will be kind of hard to do a live dump/restore on 1 machine if I cannot have two versions running. Is something not set up correctly on my machine, or in the build (pg_sphere or postgresql) that is preventing two copies from... Sigh. Never mind. The dump is spitting out the absolute path for the shared library (like it should):
>
>CREATE FUNCTION sbox_in(cstring) RETURNS sbox
> AS '/usr/local/pgsql802/lib/pg_sphere', 'spherebox_in'
> LANGUAGE c IMMUTABLE STRICT;
>
>Now if I can just figure out how to get this egg off my face...
>
>Now I remember the problem I always have, and I have a new trick in my bag:
>
>/usr/local/pgsql802/bin/pg_dumpall -c -v | sed 's/pgsql802/pgsql810/' | /usr/local/pgsql810/bin/psql -p 5433 -d template1
>
>How do others handle dumping from one version to a new one? Is there a less error prone way of doing this? As long as I don't have the string pgsql802 anywhere else...
>
>
>
>

Why use an absolute path? Why not just give the name of the .so and let
postgres find it in $libdir (i.e. sed -e 's,/usr/local/pgsql.*/lib/,,'
on your dump) ?

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Maxwell 2005-11-09 15:06:16 Re: SIGSEGV taken on 8.1 during dump/reload
Previous Message Andrew Dunstan 2005-11-09 14:47:30 Re: compiling on windows with mingw