When grilled further on (Wed, 09 Nov 2005 10:54:12 +0300), Teodor Sigaev <[EMAIL PROTECTED]> 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
pgpYYAn0aheg5.pgp
Description: PGP signature
