On 2/19/2008 2:44 AM, Peter Eisentraut wrote:
> Dave Page wrote:
>> > You can set --with-pgsharedir=whatever, and then it doesn't work.
>>
>> Right, but that option is there to tell the build system where the
>> PostgreSQL share directory is, not for you to specify where you want
>> the Slony share directory - that's how the description of the
>> parameter reads to me at least (plus of course it falls back to
>> whatever pg_config says iirc):
>>
>>   --with-pgsharedir=<dir>          Location of the PostgreSQL share
>> dir. E.g. postgresql.conf.sample
> 
> Well, let's put this differently:  The Slony installation path selection 
> procedure is insane.  I have beaten it around long enough to make it 
> installable in an FHS-like way.  If that breaks because I was using the 
> options in a sneaky way, I accept that, but please provide an alternative.

The problem is that the slonik running on system A and executing the 
command "STORE NODE" is supposed to feed the slony1_base.sql and 
slony1_funcs.sql scripts into the new node being installed. Let that new 
node be on system B. For the case that systems A and B are different 
flavors with different concepts of where things ought to be installed, 
slony1_funcs.sql references all the C language functions it installs to 
the shared library $libdir/slony1_funcs. The PostgreSQL dynamic loader 
will interpret that as <pgsharedir>/slony1_funcs<arch-specific-so-ext>.

If you insist on installing Slony objects somewhere other than the 
Postgres $libdir, you will have to change slonik in a way that allows it 
to manipulate the slony1_funcs.sql file and replace $libdir with the 
installation path of slony1_funcs.so on the system the new node is on. 
Which in a slonik script that creates a whole cluster with 4 nodes may 
well be 4 different paths.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin