Hi,

I think it would be better to be able to modify SLON_DATA_FETCH_SIZE by 
using a parameter on the slon command line. For example, we got a lot of 
updates (400 per second) between far geographical sites. I had to modify 
this variable and to recompile the slon binary cause I didn't find 
another way until now.

Regards.

Christopher Browne wrote:
> After a pretty considerable test and release cycle, version 1.2.12 of
> the Slony-I replication system has been released.
>
> There is a pretty considerable set of changes:
>
> - Fixed problem with DDL SCRIPT parser where C-style comments were
>   not being processed properly
>
> - Added stored functions and documentation for adding empty tables
>   (notably *partitions*) to replication.  Note these functions
>   do no work when not specifically requested.
>
>   CAVEAT:  This functionality may not work as expected on versions
>   of PostgreSQL earlier than 8.1.  Mind you, partitioning tends
>   to function pretty poorly in earlier versions of PostgreSQL as
>   there were substantial enhancements in 8.1 and following versions.
>
> - Added a fairly substantial partitioning test to exercise the
>   new stored functions above.
>
> - Backport "listen path" generator function from CVS HEAD (2.0) to
>   1.2 branch.
>
> - Fixed a problem with "EXECUTE SCRIPT" (introduced in remote_worker.c
>   version 1.124.2.13) where moving the relevant code into a subroutine
>   at the end led to losing the "BEGIN; SET TRANSACTION ISOLATION LEVEL
>   SERIALIZABLE;" query that needs to be the first thing run...
>
> - Fixing the archive sequence generations (in log shipping).  All
>   non-SYNC events must start the local transaction before creating the
>   archive as well, so that the lock on the archive counter table
>   serializes archive creation.
>
> - Fixed logging done in local_listener.c - various places, there was
>   no '\n' in some cases, which would lead to entries being folded
>   together.
>
> - Fix launch_slons.sh - was not stripping quotes from PID file name
>
> - Error handling for "ERROR: could not serialize access due to
>   concurrent update"
>
>   If this error is encountered when starting processing of
>   sl_archive_counter, then two threads are fighting over access to
>   this counter, and at least one has just failed.
>
>   Rather than waiting, we ask to restart the node immediately.
>
> - Fixes to slonik_build_env script - it wasn't properly handling
>   cases where there was just 1 table or 1 sequence, and had a
>   problem with the -schema option - thanks, Bernd Helmle
>
> - Don't bother building slony_logshipper on Win32 as it doesn't work
>   there at this point.
>
> - If slonik connects as other than a superuser, then generate error
>   message indicating this to the user.
>