We are pleased to present the first release candidate for version 2 of
Slony-I.  It will almost certainly not be the final for v2.0.0, but
has been tested enough (by Jan and I) that it seems worthwhile to
encourage others to test it and see if there are issues that we didn't
notice.

Differences from 1.2 stream

- Removal of TABLE ADD KEY

- It drops all support for databases prior to Postgres version 8.3.

This is required because we now make use of new functionality in
Postgres, namely the trigger and rule support for session replication
role. As of now, every node (origin/subscriber/mixed) can be dumped with
pg_dump and result in a consistent snapshot of the database.

- Still need alterTableRestore() for the upgrade from 1.2.x to 2.0.
upgradeSchema() will restore the system catalog to a consistent
state and define+configure the new versions of the log and deny_access
triggers. 

- Fix EXECUTE SCRIPT so that it records the ev_seqno for WAIT FOR EVENT
and make sure all DDL is executed in session_replication_role "local"
on the origin as well as all subscribers. This will cause the slony
triggers to ignore all DML statements while user triggers follow the
regular configuration options for ENABLE [REPLICA/ALWAYS] or DISABLE.

- Let the logshipping files also switch to session_replication_role =
"replica" or "local" (for DDL).

- Sequence tracking becomes enormously less expensive; rather than
polling *ALL* sequence values for each and every SYNC, the slon
stores the last value, and only records entries in sl_seqlog when
the value changes from that last value.  If most sequences are
relatively inactive, they won't require entries in sl_seqlog very
often.

- Change to tools/slony1_dump.sh (used to generate log shipping dump);
  change quoting of "\\\backslashes\\\" to get rid of warning

- Cleanup thread revised to push most of the logic to evaluate which
  tables are to be vacuumed into a pair of stored functions.

  This fairly massively simplifies the C code.

- Revised logging levels so that most of the interesting messages are
  spit out at SLON_CONFIG and SLON_INFO levels.  This can allow users
  to drop out the higher DEBUG levels and still have useful logs.

- Changed log selection query to be less affected by long running
  transaction.  This should help, in particular, the scenario where
  it takes a very long time to subscribe to a set.  In that situation,
  we have had the problem where applying the later SYNCs gets
  extremely costly as the query selecting logs wound up forced into a
  Seq Scan rather than an index scan.

- Removed all support for STORE/DROP TRIGGER commands. Users 
  should use the ALTER TABLE [ENABLE|DISABLE] TRIGGER functionality 
  available directly in Postgres from now on.

- Improve Wiki page generation script so that it has an option to add in
  a set of [[Category:Foo]] tags to allow automated categorization.

- Documented how to fix tables that presently use Slony-I-generated
  primary key candidates generated by TABLE ADD KEY

- Add some specific timestamps during the 2007 "DST rule change
  ambiguous time" (e.g. - during the period which, under former rules,
  was not DST, but which now is, due to the recent rule change).

  Bill Moran ran into some problems with such dates; varying
  PostgreSQL versions returned somewhat varying results.  This wasn't
  a Slony-I problem; the data was indeed being replicated correctly.

- Made configure a bit smarter about automatically locating
  docbook2man-spec.pl on Debian, Fedora, BSD.

- Tests now generate |pipe|delimited|output| indicating a number of
  attributes of each test, including system/platform information,
  versions, and whether or not the test succeeded or failed.

- Revised functions that generate listen paths

- tools/configure-replication.sh script permits specifying a
  destination path for generated config files.  This enables using
  it within automated processes, and makes it possible to use it to
  generate Slonik scripts for tests in the "test bed," which has
  the further merit of making tools/configure-replication.sh a
  regularly-regression-tested tool.

- Fix to bug #15 - where long cluster name (>40 chars) leads to
  things breaking when an index name is created that contains
  the cluster name.

  -> Warn upon creating a long cluster name.
  -> Give a useful exception that explains the cause rather
     than merely watching index creation fail.

   http://www.slony.info/bugzilla/show_bug.cgi?id=15

- Fix for bug #19 - added a script to help the administrator
  search for any triggers on the database that is the source for
  a schema that is to be used to initialize a log shipping node.

  The problem is that some/most/sometimes all triggers and rules
  are likely to need to be dropped from the log shipping node lest
  they interfere with replication.

- Elimination of custom "xxid" functions

  PostgreSQL 8.3 introduces a set of "txid" functions and a
  "txid_snapshot" type, which eliminates the need for Slony-I to have
  its own C functions for doing XID comparisons.

  Note that this affects the structure of sl_event, and leads to some
  changes in the coding of the regression tests.

  This eliminates the src/xxid directory and contents

- All of the interesting cleanup work is now done in the stored
  function, cleanupEvent(interval, boolean).

  Interesting side-effect: You can now induce a cleanup manually,
  which will be useful for testing.

- cleanupEvent now has two parameters, passed in from slon config
  parameters:

  interval - cleanup_interval (default '10 minutes')

   This controls how quickly old events are trimmed out.  It used to
   be a hard-coded value.

   Old events are trimmed out once the confirmations are aged by
   (cleanup_interval).

   This then controls when the data in sl_log_1/sl_log_2 can be
   dropped.

   Data in *those* tables is deleted when it is older than the
   earliest XID still captured in sl_event.

  boolean - cleanup_deletelogs (default 'false')

   This controls whether or not we DELETE data from sl_log_1/sl_log_2

   By default, we now NEVER delete data from the log tables; we
   instead use TRUNCATE.

- We now consider initiating a log switch every time cleanupEvent()
  runs.

  If the call to logswitch_finish() indicates that there was no log
  switch in progress, we initiate one.

  This means that log switches will be initiated almost as often as
  possible.  That's a policy well worth debating :-).

- logswitch_finish() changes a fair bit...

  It uses the same logic as in cleanupEvent() to determine if there
  are any *relevant* tuples left in sl_log_[whatever], rather than
  (potentially) scanning the table to see if there are any undeleted
  tuples left.

- At slon startup time, it logs (at SLON_CONFIG level) all of the
  parameter values.  Per Bugzilla entry #21.

  http://www.slony.info/bugzilla/show_bug.cgi?id=21

- New slonik "CLONE PREPARE" and "CLONE FINISH" command to assist in
  creating duplicate nodes based on taking a copy of some existing
  subscriber node.

- We no longer use LISTEN/NOTIFY for events and confirmations, which
  eliminates the usage that has caused pg_listener bloat.  We instead
  poll against the event table.

- Various instances where slonik would use a default node ID of 1 have
  been changed to remove this.

  Slonik scripts may need to be changed to indicate an EVENT NODE (or
  similar) after migration to v2.0 as a result.

  The slonik commands involved:

  - STORE NODE - EVENT NODE
  - DROP NODE - EVENT NODE
  - WAIT FOR EVENT - WAIT ON
  - FAILOVER - BACKUP NODE
  - EXECUTE SCRIPT - EVENT NODE

- Fixed a problem where ACCEPT_SET would wait for the corresponding
  MOVE_SET or FAILOVER_SET to arrive while holding an exclusive lock
  on sl_config_lock, preventing the other remote worker to process
  that event.

-- 
"cbbrowne","@","ca.afilias.info"
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)