Re: SIGSEGV taken on 8.1 during dump/reload

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: SIGSEGV taken on 8.1 during dump/reload
Дата
Msg-id 43720E33.8010306@dunslane.net
обсуждение исходный текст
Ответ на Re: SIGSEGV taken on 8.1 during dump/reload  (Robert Creager <Robert_Creager@LogicalChaos.org>)
Ответы Re: SIGSEGV taken on 8.1 during dump/reload  (Robert Creager <Robert.Creager@Sun.com>)
Список 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
cannothave 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
theshared 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
asI 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: compiling on windows with mingw
Следующее
От: Gregory Maxwell
Дата:
Сообщение: Re: SIGSEGV taken on 8.1 during dump/reload