#+OPTIONS: ^:{}
* 2.2.3
  - Bug 338 - Have ddlScript return a bigint instead of a integer
  - fixing  Deadlock with application during minor version slony upgrade
  - Bug 342 FAILOVER fixes for some multi-node configurations
  - Remove HAVE_POSIX_SIGNALS from config.h
  - Bug 344 Do not abort reading slon config values when an unrecognized one is encountered
  
* 2.2.2

 - Include server include paths on --with-pgport builds  for slonik

 - Bug 327 - Fix invalid free() in the logApply trigger

* 2.2.1
  - Bug 315 :: Fixes to compile time include directories

  - Bug 318 :: Fix to FAILOVER logic to avoid slon restart loop

  - Bug 319 :: Fix dereferencing of NULL pointer on a lost connection

  - Bug 320 :: Fix UPDATE FUNCTIONS so it adds sl_node.no_failed on a upgrade
               from slony version before 2.2.0

  - Bug 321 :: Fixing frequent slon connect and disconnects to providers

  - Bug 322 :: Allow CLONE PREPARE processing to deal with an earlier STORE PATH

  - No Bug  :: remove warning unsupported warning for PG 9.3

* Slony-I 2.2 Release Notes

** Significant Changes

   - Shared Libraries are now named so as to allow having multiple
     versions of Slony installed simultaneously on a database cluster

     - Bug 287 :: Fix UPDATE FUNCTIONS so it works when the old shared
                  library is no longer around

     - Bug 290 :: Make the symbols in the shared library unique 

     - The slony1_funcs.so and .sql files that get installed are also
       versioned, which allows multiple versions of slony to be
       installed in the same postgresql lib directory.

   - Allow linking with pgport on 9.3+ by including pgcommon

   - Let DDL for EXECUTE SCRIPT to be specified inline - bug 151

   - Numerous revisions to documentation

   - altperl tool improvements including ::
     - better support for running multiple slons on the same server
     - let start_slon invoke slon with a config file
     - fix node_is_subscribing
     - $LOGDIR directory behaviours
     - use PGPASSWORDFILE when querying state
     - Add correct 'ps' arguments to the altperl tools for Darwin.

   - SYNC GROUP sizes are now dynamically grow from 1 to a maximum
     size set in the config file.  The old logic based on time it took
     to complete the last SYNC has been removed.  - bug #235

   - Added a RESUBSCRIBE NODE command to reshape clusters. This must
     be used instead of SUBSCRIBE SET to reshape subscriptions when an
     origin has more than one set.

   - Bug #178 :: The FAILOVER process has been reworked to be more
                 reliable. Some nodes can no longer be used as
                 failover targets.

   - SET ID is no longer an option to EXECUTE SCRIPT.

   - Major "protocol" change; rather than constructing cursors to
     query logged updates, version 2.2 now uses the COPY protocol to
     stream data into log tables on subscribers.  This is discussed in
     greater detail in the following section.

** Major 2.2 change: COPY protocol

    In versions before 2.2, Slony-I log triggers would capture logged
    data into tables ~sl_log_1~ and ~sl_log_2~ in the form of
    nearly-"cooked" queries, omitting just the INSERT/UPDATE/DELETE
    statement, and the slon that processes the data would transform
    the data into INSERT/UPDATE/DELETE statements to be individually
    parsed and executed by the subscriber node.

    In version 2.2, this is changed fairly massively.

    - Log triggers

      - Log triggers used to capture the text of the SQL statement to
        perform the INSERT/UPDATE/DELETE, missing only the literal
        INSERT (or UPDATE or DELETE) and the name of the table.

      - As of version 2.2, the log triggers now capture an array of
        text values indicating the criteria and the data to be loaded.

    - Query against data provider

      - The old query process used to involve declaring a cursor
        called LOG, which would pull in all the tuples where the data
        attribute was not "too terribly large."  Tuples would be
        pulled in a few hundred at a time, the unusually large ones
        being handled via a special side process in order to avoid
        excessive memory consumption.

      - In version 2.2, the query instead runs a COPY to standard
        output, leaving a pipe open to capture that output for
        transmission to the subscriber.

    - Loading data into subscriber

      - The old query process involved explicitly running each INSERT,
        UPDATE, DELETE, and TRUNCATE against the subscriber.  This
        required that the backend parse, plan, and process each query
        individually.

      - In version 2.2, the stream of data captured from the COPY
        request is, in turn, passed to a COPY statement that loads the
        data into sl_log_1 or sl_log_2 on the subscriber node.

        A trigger on sl_log_1 and sl_log_2 reads the incoming data
        and, inside the backend, transforms the array into
        INSERT/UPDATE/DELETE statements.

     	This is still an oversimplification; there is a statement
        cache so that if there is request to ~INSERT INTO some_table
        (c1,c2) values ('b','c');~ followed (perhaps, but not
        necessarily immediately) by ~INSERT INTO some_table (c1,c2)
        values ('d','e');~, then the second request re-uses the plan
        from the first query, and may instead execute ~EXECUTE
        some_table_insert('d','e');~

    - DDL handling

	  - The old behaviour was that DDL was treated as a special Slony
        event, and it never was clear whether that should be executed
        before or after other replication activity that might have
        taken place during that Slony event.  This was fine in Slony
        1.2 and earlier, when the processing of DDL forcibly required
        that Slony take out locks on the origin on ALL replicated
        tables; those locks would prevent there from being any other
        activity going on during the processing of DDL.  But when much
        of that locking disappeared, in version 2.0, it became
        possible for there to be replication activity on tables not
        being modified by DDL, and timing anomalies could occur.

	  - In version 2.2, a third log table, sl_log_script, is added to
        capture script queries which would notably include DDL.  This
        table uses the same sequence value that controls order of
        application for replicated data, so DDL will be applied at
        exactly the appropriate point in the transaction stream on
        subscribers.

        - Note that this rectifies bug #137, *execute script does not
          get applied in the correct order*

      - Sequence handling changes somewhat (see Bug 304).

		Previously, when DDL was processed as "an event," this would
        naturally mean that sequence values would have values based on
        the previous SYNC, and, at the end, capture values at the end
        of the DDL SYNC, and the "DDL Sync" could make use of those
        values.

		Now, with DDL being processed along with ordinary replicated
        DML within a SYNC, sequence usage by DML needs to be captured
        and mixed into the updates.  Now, each time a DDL statement is
        applied, sequences need to be updated, which can now take
        place in the middle of a SYNC.		

    - Expected effects
      - Lower processing overhead in slon process :: By using COPY,
           all that need be done is for slon to "stream" data from the
           provider to the subscriber.  There is no longer a need to
           generate or process individual queries.
      - Lower memory consumption in slon process :: Again, from using
           COPY, memory consumption is based solely on how much data
           is buffered in memory as part of the streaming.  A query
           that is larger than the buffer is simply handled by letting
           data stream through the buffer; the large query does not
           need to be instantiated in memory, as was the case in older
           versions of Slony.
      - Less query processing work on subscriber database :: The use
           of prepared statements should dramatically reduce the
           amount of computational effort required for query parsing
           and planning.
      - Correct ordering of DDL within processing :: Bug #137
           described a problem persisting from version 2.0 to 2.1
           where DDL could be performed in the wrong order with
           respect to logged data changes.  The shift of "script" data
           from ~sl_event~ to ~sl_log_script~ resolves this issue.
   
** Bugs fixed in the course of the release

	These are expected to represent bugs that were previously present,
	not a consequence of problems introduced and subsequently fixed in
	the 2.2 branch.

- No bug  :: Make log_truncate() SECURITY DEFINER
- Bug 250 :: Log shipper does not report application name - add in setting of GUC
- Bug 252 :: cloneNodePrepare() store a valid conninfo in sl_path
- Bug 273 :: Slon can try to pull data from a behind provider.  Fix is
             to not force the event provider to be part of the
             providers unless we don't find any provider at all
             otherwise.
- Bug 286 :: Support to compile against PG 9.3
- Bug 297 :: Make test_slony_state-dbi.pl work with PG 9.2
- Bug 299 :: Fix a bug in MOVE SET where slon might pull data from the old origin using
             SYNC values for the new origin


