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. - Bug #54 - quite a few Bash-isms in various scripts have been addressed so as to make the shell scripts more portable. - Bug #18 - the function parameter for the logtrigger functions no longer requires any trailing v's Add a test to "test1" to make sure this logic gets exercised. - Created "start_slon.sh", an rc.d-style script for starting, stopping, and checking status of slon processes. Integrated this into the regression tests, replacing previous logic for starting/stopping slons, so that this script can be considered carefully tested - Bug #46 - incompatibility with PostgreSQL 8.4 addressed - Use dollar quoting in stored functions - Additional logging of the time spent running queries, broken out on a by-database basis - Fixes to documentation of WAIT FOR EVENT - Fix to bug #63 - cleanup thread had an imperative SELECT that needed to become part of an IF statement - Enhancement - bug #61 - logshipper process should rescan the queue when it empties - Note about "duct tape" tests: There are many of these tests that reside in src/ducttape that reference features removed in v2.0. We will eventually be replacing these with a more proper "test suite" so we're not remedying all the ducttape tests.