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

Modified Files:
	frontpage.txt news.txt 
Log Message:
Update for v2.0.0


Index: frontpage.txt
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/content/frontpage.txt,v
retrieving revision 1.30
retrieving revision 1.31
diff -C2 -d -r1.30 -r1.31
*** frontpage.txt	24 Sep 2008 21:32:44 -0000	1.30
--- frontpage.txt	25 Nov 2008 03:43:26 -0000	1.31
***************
*** 1,11 ****
  ---
! Slony-I 2.0.0 second release available
! 
! <P> Version 2.0.0 RC2 is now <a href=
! "http://slony.info/downloads/2.0/source/slony1-2.0.0-rc2.tar.bz2">
! available.</a>
  
! See the "news" area for more details, including a copy of the release
  notes.
  ---
  Slony-I 1.2.15 available
--- 1,19 ----
  ---
! Slony-I 2.0.0 Released
  
! <P> See the "news" area for more details, including a copy of the release
  notes.
+ 
+ <P> This is a <i>major</i> new release of Slony-I; it makes use of
+ some features introduced in PostgreSQL 8.3, and hence is not
+ compatible with versions older than 8.3.
+ 
+ <P> This is considered a pretty good tradeoff, as various
+ functionality would not be possible with earlier versions of
+ PostgreSQL.
+ <ul>
+ <li> Internal catalogues are no longer "hacked with," so that you may, with the new version, use pg_dump against subscribers and be able to expect to have a complete and consistent dump.
+ <li> Trigger handling is <i>enormously</i> cleaner.
+ </ul>
  ---
  Slony-I 1.2.15 available

Index: news.txt
===================================================================
RCS file: /home/cvsd/slony1/slony1-www/content/news.txt,v
retrieving revision 1.48
retrieving revision 1.49
diff -C2 -d -r1.48 -r1.49
*** news.txt	24 Sep 2008 21:32:44 -0000	1.48
--- news.txt	25 Nov 2008 03:43:26 -0000	1.49
***************
*** 5,8 ****
--- 5,11 ----
  Chris Browne
  
+ Slony-1 2.0.0 <a href="http://main.slony.info/downloads/2.0/source/slony1-2.0.0.tar.bz2">engine</a>
+ <a href="http://main.slony.info/downloads/2.0/source/slony1-2.0.0-docs.tar.bz2">documentation</a>
+ <br/>
  Slony-1 1.2.15 <a href="http://main.slony.info/downloads/1.2/source/slony1-1.2.15.tar.bz2">engine</a>
  <a href="http://main.slony.info/downloads/1.2/source/slony1-1.2.15-docs.tar.bz2">documentation</a>
***************
*** 11,14 ****
--- 14,253 ----
  <!-- Please keep this item at the top of the news list -->
  ---
+ Slony-I 2.0.0 Released
+ http://main.slony.info/downloads/2.0/source/slony1-2.0.0.tar.bz2
+ 2008-11-24
+ Chris Browne
+ 
+ Differences from 1.2 stream
+ 
+ <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.
+ 
+   <P> Warn upon creating a long cluster name.
+   <p> Give a useful exception that explains the cause rather
+      than merely watching index creation fail.
+ 
+ <p><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 *those* 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.
+ 
+ <li> Bug #54 - quite a few Bash-isms in various scripts have been
+   addressed so as to make the shell scripts more portable.
+ 
+ <li> Bug #18 - the function parameter for the logtrigger functions no
+   longer requires any trailing v's
+ 
+ <P>  Add a test to "test1" to make sure this logic gets exercised.
+ 
+ <li> Created "start_slon.sh", an rc.d-style script for starting,
+   stopping, and checking status of slon processes.
+ 
+ <P>  Integrated this into the regression tests, replacing previous
+   logic for starting/stopping slons, so that this script can be
+   considered carefully tested
+ 
+ <li> Bug #46 - incompatibility with PostgreSQL 8.4 addressed
+ 
+ <li> Use dollar quoting in stored functions
+ 
+ <li> Additional logging of the time spent running queries, broken out on
+   a by-database basis
+ 
+ <li> Fixes to documentation of WAIT FOR EVENT
+ 
+ <li> Fix to bug #63 - cleanup thread had an imperative SELECT that needed
+   to become part of an IF statement
+ 
+ <li> Enhancement - bug #61 - logshipper process should rescan the queue
+   when it empties
+ 
+ <li> Note about "duct tape" tests:  There are many of these tests that
+   reside in src/ducttape that reference features removed in v2.0.
+ 
+ <P>  We will eventually be replacing these with a more proper "test suite"
+   so we're not remedying all the ducttape tests.
+ </ul>
+ ----
  Slony-I 2.0.0 second RC available
  http://main.slony.info/downloads/2.0/source/slony1-2.0.0-rc2.tar.bz2