Christopher Browne wrote:
> We are pleased to have a second release candidate for Slony-I 1.2...
> See the announcement at <http://slony.info/>; it shows URLs for both the
> source tarball and for pre-built documentation.
> <http://pgfoundry.org/frs/download.php/1012/slony1-1.2.0-rc2.tar.bz2>
> Changes since RC1 include:
> 
>     * Generates partial indexes on demand on sl_log_N tables
>     * Fix 8.2 problem - need to have connections set
>       standard_conforming_strings = off
>     * Properly declare 7.3 to be unsupported in slonik
>     * slony1-funcs.sql had a CONTINUE statement only supported in PG 8.0+
>     * Fixes to RPM specs
>     * Additional error checking in log shipping code
>     * Documentation answering "When is it OK to kill off slons???"
>     * Added to documentation lists of most error messages that can be
>       generated, along with why they might happen
> 
> I have since added a test that exercises inheritance, which evidently
> works fine...
> 
> We have noticed two further issues thus far:
> - There was a minor incompatibility with 8.2; our #includes didn't
> include all required objects.  If you are trying to run this on 8.2, see
> the following (tiny!) patch:
> <http://gborg.postgresql.org/pipermail/slony1-commit/2006-August/001107.html>
> This seems trivial enough that it wouldn't seem to me to warrant an RC3
> in and of itself...
> 
> - *Stefan Kaltenbrunner aka "mastermind" has been* experiencing problems
> trying to compile Slony-I on Windows; **** he's hitting issues at
> ./configure time.  If others with experience with this can visit IRC
> (irc.freenode.net, channel #slony), that might be helpful.  Windows does
> have its peculiarities, so perhaps there needs to be more documentation
> on how the build process works...
> 
> It's not evident whether there are new Windows issues, or whether the
> "struggle" is one inherent to the platform.

well there are multiple issues or gotchas as I see it:

*) configure fails to work with --pgconfigdir since it is looking for a
binary called pg_config not pg_config.exe - darcy already has a patch
for that

*) there is some hardcoded(!) override in configure for mingw32 that
results in a number of --pgXXX commandline flags to get ignored and also
ignores what pg_config has to say about the location of certain things.

*) related to the above point - the include directory layout postgresql
generates here-  after a make install - does NOT match what configure
tries to hardcode - though the ones pg_config is reporting are correct
(though windows style)

*) there seems to be an undocumented (?) dependency on some external
win32 pthread port - msys/mingw as I have it does not seem to include
those soe even after fixing/hacking up the configure script slony fails
at the make step


comments ?

Stefan