Update of /home/cvsd/slony1/slony1-www/content
In directory main.slony.info:/tmp/cvs-serv18500/content

Modified Files:
	frontpage.txt news.txt 
Log Message:
Add notes on 2.0.0 rc1


Index: frontpage.txt
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/content/frontpage.txt,v
retrieving revision 1.27
retrieving revision 1.28
diff -C2 -d -r1.27 -r1.28
*** frontpage.txt	16 May 2008 17:48:09 -0000	1.27
--- frontpage.txt	27 Jun 2008 20:38:28 -0000	1.28
***************
*** 14,17 ****
--- 14,26 ----
  
  ---
+ Slony-I 2.0.0 first release available
+ 
+ <P> Version 2.0.0 RC1 is now <a href=
+ "http://slony.info/downloads/2.0/source/slony1-2.0.0-rc1.tar.bz2">
+ available.</a>
+ 
+ See the "news" area for more details, including a copy of the release
+ notes.
+ ---
  Slony-I 1.2.14 available
  

Index: news.txt
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/content/news.txt,v
retrieving revision 1.44
retrieving revision 1.45
diff -C2 -d -r1.44 -r1.45
*** news.txt	16 May 2008 17:48:09 -0000	1.44
--- news.txt	27 Jun 2008 20:38:28 -0000	1.45
***************
*** 11,14 ****
--- 11,220 ----
  <!-- Please keep this item at the top of the news list -->
  ---
+ Slony-I 2.0.0 first RC available
+ http://main.slony.info/downloads/2.0/source/slony1-2.0.0-rc1.tar.bz2
+ 2008-06-27
+ Chris Browne
+ 
+ Now available is a first release candidate of version 2.0 of Slony-I,
+ involving a large number of enhancements done over the last year or
+ so.<br>
+ 
+ <b>Differences from 1.2 stream</b>
+ 
+ <ul>
+ <li> Removal of TABLE ADD KEY
+ 
+ <li> It drops all support for databases prior to Postgres version 8.3.
+ 
+ <P> 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.
+ 
+ <li> 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. 
+ 
+ <li> 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.
+ 
+ <li> Let the logshipping files also switch to session_replication_role =
+ "replica" or "local" (for DDL).
+ 
+ <li> 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.
+ 
+ <li> Change to tools/slony1_dump.sh (used to generate log shipping dump);
+   change quoting of "\\\backslashes\\\" to get rid of warning
+ 
+ <li> Cleanup thread revised to push most of the logic to evaluate which
+   tables are to be vacuumed into a pair of stored functions.
+ 
+ <P>  This fairly massively simplifies the C code.
+ 
+ <li> 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.
+ 
+ <li> 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.
+ 
+ <li> 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.
+ 
+ <li> Improve Wiki page generation script so that it has an option to add in
+   a set of [[Category:Foo]] tags to allow automated categorization.
+ 
+ <li> Documented how to fix tables that presently use Slony-I-generated
+   primary key candidates generated by TABLE ADD KEY
+ 
+ <li> 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).
+ 
+ <P>  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.
+ 
+ <li> Made configure a bit smarter about automatically locating
+   docbook2man-spec.pl on Debian, Fedora, BSD.
+ 
+ <li> 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.
+ 
+ <li> Revised functions that generate listen paths
+ 
+ <li> 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.
+ 
+ <li> 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.
+ 
+ <ul>
+   <li> Warn upon creating a long cluster name.
+   <li> Give a useful exception that explains the cause rather
+      than merely watching index creation fail.
+ </ul>
+ 
+    See <a href="http://www.slony.info/bugzilla/show_bug.cgi?id=15"> Bug #15 </a>
+ 
+ <li> 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.
+ 
+ <p>  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.
+ 
+ <li> Elimination of custom "xxid" functions
+ 
+ <P>  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.
+ 
+ <P>  Note that this affects the structure of sl_event, and leads to some
+   changes in the coding of the regression tests.
+ 
+ <P>  This eliminates the src/xxid directory and contents
+ 
+ <li> All of the interesting cleanup work is now done in the stored
+   function, cleanupEvent(interval, boolean).
+ 
+ <P>  Interesting side-effect: You can now induce a cleanup manually,
+   which will be useful for testing.
+ 
+ <li> cleanupEvent now has two parameters, passed in from slon config
+   parameters:
+ 
+ <P>  interval - cleanup_interval (default '10 minutes')
+ 
+ <P>   This controls how quickly old events are trimmed out.  It used to
+    be a hard-coded value.
+ 
+ <P>   Old events are trimmed out once the confirmations are aged by
+    (cleanup_interval).
+ 
+ <P>   This then controls when the data in sl_log_1/sl_log_2 can be
+    dropped.
+ 
+ <P>   Data in <i>those</i> tables is deleted when it is older than the
+    earliest XID still captured in sl_event.
+ 
+ <p>  boolean - cleanup_deletelogs (default 'false')
+ 
+ <P>   This controls whether or not we DELETE data from sl_log_1/sl_log_2
+ 
+ <P>   By default, we now NEVER delete data from the log tables; we
+    instead use TRUNCATE.
+ 
+ <li> We now consider initiating a log switch every time cleanupEvent()
+   runs.
+ 
+ <P>  If the call to logswitch_finish() indicates that there was no log
+   switch in progress, we initiate one.
+ 
+ <P>  This means that log switches will be initiated almost as often as
+   possible.  That's a policy well worth debating :-).
+ 
+ <li> logswitch_finish() changes a fair bit...
+ 
+ <P>  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.
+ 
+ <li> At slon startup time, it logs (at SLON_CONFIG level) all of the
+ parameter values.  Per <a
+ href="http://www.slony.info/bugzilla/show_bug.cgi?id=21"> Bugzilla
+ entry #21.</a>
+ 
+ <li> New slonik "CLONE PREPARE" and "CLONE FINISH" command to assist in
+   creating duplicate nodes based on taking a copy of some existing
+   subscriber node.
+ 
+ <li> 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.
+ 
+ <li> Various instances where slonik would use a default node ID of 1 have
+   been changed to remove this.
+ 
+ <P>  Slonik scripts may need to be changed to indicate an EVENT NODE (or
+   similar) after migration to v2.0 as a result.
+ 
+ <P>  The slonik commands involved:
+ 
+ <ul>
+   <li> STORE NODE - EVENT NODE
+   <li> DROP NODE - EVENT NODE
+   <li> WAIT FOR EVENT - WAIT ON
+   <li> FAILOVER - BACKUP NODE
+   <li> EXECUTE SCRIPT - EVENT NODE
+ </ul>
+ <li> 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.
+ </ul>
+ ---
  Slony-I 1.2.14 available
  http://main.slony.info/downloads/1.2/source/slony1-1.2.14.tar.bz2