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
