As far as I'm aware, it's always been expected that Postgres and Slony share the same installation directories.

I don't know whose expectations you are citing, but it certainly has not been the case in the last 3 years or so since I have been dealing with it that Slony had to share the PostgreSQL installation path.  If that were the case, it would be quite a serious and unnecessary restriction.  For example, you could never do any test installations.

I'm recalling a thread in which someone complained that Slony installs itself into the Postgres directory structure to which (iirc) the response was that it was an intentional design choice for it to be installed that way.

Anyhoo, if it previously worked I certainly don't have any desire to break that, however I do think it's important to be able to support relocated installs. Any thoughts on how we might do both?

It seems to me that we already have enough hooks for this to work.

--> If you specify, at configure time, --with-pgconfigdir, that will use pg_config to establish defaults based on where PostgreSQL components "live."

--> You can override those via the various --with-pg* configure flags, that will override any bits of pg_config that you might want to override.

I *think* that if we roll back the patch, that will allow the use of the above pair of kinds of configuration to handle this.

That doesn't help in a relocatable install where the final location is unknown at build time. Postgres is able to locate it's share directory at runtime (something which is essential on Windows for example), and the current code takes advantage of that on all platforms as well as Windows as it did previously.

The reason I ran into this was building bundles of packages in a staging area for later installation into a user-defined location. Everything worked perfectly bar slonik.

(In reply to comment #5)
> That doesn't help in a relocatable install where the final location is unknown
> at build time. Postgres is able to locate it's share directory at runtime
> (something which is essential on Windows for example), and the current code
> takes advantage of that on all platforms as well as Windows as it did
> previously.
> 
> The reason I ran into this was building bundles of packages in a staging area
> for later installation into a user-defined location. Everything worked
> perfectly bar slonik.

If it doesn't help, then we nonetheless need to either:

a) Come up with an answer that addresses both situations, or

b) We'll have to roll back so that we can *at least* have correct results for the cases where the final location *is* known, as that case is presently breaking.

I suppose you should alter get_share_path(), find_my_exec(), and so on to work relative to Slony's installation directories, not PostgreSQL's.  Maybe a bit of refactoring would do the trick.

A fix is being worked on...

FWIW, here is my experience with this bug:

I am in the process of upgrading my test cluster from Pg 8.2 to 8.3, so the first step was installing Slony 1.2.13 which has Pg 8.3 support.

After compiling (./configure --pgconfdir=/usr/local/pgsql/bin/pg_config --prefix=/usr/local/slony-1.2.13-2008021800 --with-perltools) and installing Slony (make install), I then proceeded to upgrade the slony schemas using slonik_update_nodes after shutting down old slon daemons.

But it failed with this error:

# slonik_update_nodes | slonik
<stdin>:3: could not open file /usr/local/slony-1.2.13-2008021800/share/slony1_funcs.sql

I found slony1_funcs.sql in pgsql/share which is apparently where it used to live.

I temporarily worked around this issue by copying all the slony scripts to the slony/share folder.

Regardless of where the scripts should live, at the very least with a simple install like this slony should find the scripts wherever they happen to be.

Yes, under separate cover, I removed the -lpgport reference...

The trouble is that this does not work on PG 7.4.  If it is apropos for versions 8.0 and newer, then we need to address this via a change to "configure" (hence to the m4 scripts).

It sounds as though -lpgport needs to return, in that fashion.

In watching the discussion, I'm not yet sure of the answer.  It *does* seem to me that we should try to handle this for the v1.2 branch by trying to be consistent with previous 1.2 behaviour.

Thus, the *real*, long term answer should go into HEAD.  We mayn't be able to address all of Peter's issues for 1.2.14, and that should not be considered a disaster.

Hmm, didn't realise the tracker didn't pickup email traffic :-(

Anyway, how about the following:

For 1.3 we use -lpgport (because 1.3 will only support 8.3+ anyway), and use the configure-time PGSHARE directory, or if it doesn't exist or doesn't contain the scripts, fall back to get_share_path().

For 1.2:

For PostgreSQL 7.4, builds we only use PGSHARE.

For PostgreSQL 8.0+, we behave per Slony 1.3, first trying PGSHARE, then falling back to get_share_path() (the reason for that order btw, is to ensure Peter's test build gets used in preference to any existing production installation).

How does that sound? If everyone is happy with that, I'll code something up (might have to wait until after FOSDEM though).

Dave, that approach (with the two strategies, respectively, for 1.2 and HEAD) seems satisfactory to me.  I think Peter needs to weigh in...

The problem is really that get_share_path() works relative to the PostgreSQL installation, not the Slony installation.  You need to change it so that it finds Slony's sharedir relative to Slony's bindir.  That should work perfectly fine for all situations, as long as you leave the PostgreSQL installation paths out of the picture.

If you *want* to have Slony installed in the same paths as PostgreSQL, then you can run Slony's configure with --prefix=/usr/local/pgsql and you are there.

But 99.9% of people will run Slony in exactly this way, as originally intended.

My proposal will return the old behaviour so your case works, and if it cannot find the scripts will fallback to using get_share_path(). 

Will that meet your requirements?

(In reply to comment #14)
> But 99.9% of people will run Slony in exactly this way, as originally intended.

I'm sure you don't have anything to support these numbers.  I have *never* run Slony this way, in many installations.

> My proposal will return the old behaviour so your case works, and if it cannot
> find the scripts will fallback to using get_share_path(). 
> 
> Will that meet your requirements?

Please supply a patch and I'll check it.

Created attachment 8 [details]
Patch to search the Slony share dir for scripts before falling back to the PG share dir on 8.0+

Dave's patch appears to work.  At least slonik_update_nodes refers to the "correct" file for me now.

Applied patch to 1.2 branch...

For your information, I had the *exact* same problem as David Rees, as we use custom and different paths for both Slony and PostgreSQL.

While trying to upgrade to Slony 1.2.13 I met the same bug, and fixed it by linking PG's share to Slony's share.