Update of /home/cvsd/slony1/slony1-engine
In directory main.slony.info:/tmp/cvs-serv8215

Modified Files:
	TODO 
Log Message:
Added a LOT of items to the not-much-updated TODO list


Index: TODO
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/TODO,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** TODO	15 Apr 2005 19:33:15 -0000	1.3
--- TODO	5 Jul 2007 19:50:01 -0000	1.4
***************
*** 1,4 ****
! * Documentation
! ----------------
  
! -Provide instructions on how to upgrade from 1.0 to 1.1
--- 1,120 ----
! ToDo List for Slony-I
! -----------------------------------------
  
! $Id$
! 
! Documentation Improvements
! --------------------------------------------
! 
! - Document how to fix tables that presently use Slony-I-generated
!   primary key candidates generated by TABLE ADD KEY
! 
! - Removed all support for STORE/DROP TRIGGER commands. Users are
!   supposed to use the ALTER TABLE [ENABLE|DISABLE] TRIGGER
!   functionality in Postgres from now on.
! 
! 
! Short Term Items
! ---------------------------
! 
! CANCEL SUBSCRIPTION
!    <http://lists.slony.info/pipermail/slony1-hackers/2007-May/000011.html>
! 
! Improve script that tries to run UPDATE FUNCTIONS across versions to
! verify that upgrades work properly.
! 
! Improve Wiki page generation script so that it has an option to add in
! a set of [[Category:Foo]] tags to allow automated categorization.
! 
! 
! Bill Moran had some timestamps that were not handled well; should make
! sure that these specific timestamps are included in our test cases...
! 
! 03/12/2007 11:05:32.913154 edt vs. 03/12/2007 10:05:32.913154 est
! 03/14/2007 17:39:28.595669 edt vs. 03/14/2007 16:39:28.595669 est
! 03/28/2007 14:45:55.75936 edt  vs. 03/28/2007 13:45:55.75936 est
! 03/29/2007 13:35:19.960505 edt vs. 03/29/2007 12:35:19.960505 est
! 
! - Add Drew Hammond's "mkservice" scripts to the 1.2 branch
! 
! - update autoconf to be better aware of where DocBook document
!   generation tools live
! 
! Longer Term Items
! ---------------------------
! 
! - Add more tests (what???) to test_slony_state script(s).
! 
!   e.g. - add a warning if there exist tables with generated PK.
! 
! - Use PGXS
! 
! - Windows-compatible version of tools/slony1_dump.sh
! 
! - Clone Node - use pg_dump/PITR to populate a new subscriber node
! 
! Wishful Thinking
! ----------------------------
! 
! SYNC pipelining
! 
!   - the notion here is to open two connections to the source DB, and
!     to start running the queries to generate the next LOG cursor while
!     the previous request is pushing INSERT/UPDATE/DELETE requests to
!     the subscriber.
! 
! COPY pipelining
! 
!   - the notion here is to try to parallelize the data load at
!     SUBSCRIBE time.  Suppose we decide we can process 4 tables at a
!     time, we set up 4 threads.  We then iterate thus:
! 
!     For each table
!        - acquire a thread (waiting as needed)
!        - submit COPY TO stdout to the provider, and feed to 
!          COPY FROM stdin on the subscriber
!        - Submit the REINDEX request on the subscriber
! 
!     Even with a fairly small number of threads, we should be able to
!     process the whole subscription in as long as it takes to process
!     the single largest table.
! 
!     This introduces a risk of locking problems not true at present
!     (alas) in that, at present, the subscription process is able to
!     demand exclusive locks on all tables up front; that is no longer
!     possible if the subscriptions are split across multiple tables.
!     In addition, the updates will COMMIT across some period of time on
!     the subscriber rather than appearing at one instant in time.
! 
!     The timing improvement is probably still worthwhile.
! 
!     http://lists.slony.info/pipermail/slony1-hackers/2007-April/000000.html
! 
! Slonik ALTER TABLE event
! 
!     This would permit passing through changes targeted at a single
!     table, and require much less extensive locking than traditional
!     EXECUTE SCRIPT.
! 
! Compress DELETE/UPDATE/INSERT requests
! 
!     Some performance benefits could be gotten by compressing sets of
!     DELETEs on the same table into a single DELETE statement.  This
!     doesn't help the time it takes to fire triggers on the origin, but
!     can speed the process of "mass" deleting records on subscribers.
! 
!     <http://lists.slony.info/pipermail/slony1-general/2007-July/006249.html>
! 
!     Unfortunately, this would complicate the application code, which
!     people agreed would be a net loss...
! 
!     <http://lists.slony.info/pipermail/slony1-general/2007-July/006267.html>
! 
! Data Transformations on Subscriber
! 
!     Have an alternative "logtrigger()" scheme which permits creating a
!     custom logtrigger function that can read both OLD.* and NEW.* and
!     assortedly:
! 
!     - Omit columns on a subscriber
!     - Omit tuples