Re: SIGSEGV taken on 8.1 during dump/reload

When grilled further on (Wed, 09 Nov 2005 10:54:12 +0300),
Teodor Sigaev <teodor@sigaev.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
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
IMMUTABLESTRICT; 

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
Idon'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