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
|
Список | 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 по дате отправления: