Re: SIGSEGV taken on 8.1 during dump/reload

When grilled further on (Wed, 09 Nov 2005 10:54:12 +0300),
Teodor Sigaev <teodor(at)sigaev(dot)ru> confessed:

> > So, I'm as sure as I can be right now. How can I check the .so files installed
> > by the build? Do they reference an absolute path for their dependent .so files
> > (postgres), or will they use ld.so.conf, which might then explain the problem.
> > My ld.so.conf still points to the 8.0.2 version, as I've not switched yet to
> > 8.1.0.
>
> The simplest way is just remove pg_sphere.so in 8.1 installaion
> (/usr/local/pgsql810/lib/pg_sphere.so) and try, for example, to create gist
> index on spoint. Response should be:
> contrib_regression=# create index test_data_index on test_data using gist( loc );
> ERROR: could not access file "/usr/local/pgsql/lib/pg_sphere": No such file or
> directory
>
>
> If not - 8.1 use 8.0 .so....

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

Sorry for the bandwidth,
Rob

--
07:14:34 up 37 days, 23:49, 6 users, load average: 2.20, 2.17, 2.16
Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004