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

Added Files:
	RELEASE 
Log Message:
Merge all RELEASE-1.2* files into one file.



--- NEW FILE: RELEASE ---
$Id: RELEASE,v 1.2 2007-05-28 20:20:57 devrim Exp $

RELEASE 1.2.10

- Fixed problem with EXECUTE SCRIPT (EXECUTE ONLY ON = <node>)

  - The script was being executed on too many nodes...

- Added a test script for log shipping

  ... And alter it to add invocation of a DDL script.  This
  allows testing for an event-counting problem in log shipping.

- Changes to support PostgreSQL 8.3 as VARATT_SIZEP has been deprecated

- in xxid.c, changes to support PostgreSQL 8.3 as tuple compression has
  more extensive support

  VARDATA_ANY(PG_DETOAST_DATUM_PACKED((PG_GETARG_DATUM(0))))
  tends to replace
  PG_GETARG_VARLENA(0)


- Slonik's SYNC command never recorded the new seqno in the admin
  conninfo, with potential wacky results for WAIT FOR EVENT


- Fix rpm build problem when the system has pg_config in both under
  /usr/local/pgsql/bin and /usr/bin

- Add init script for Red Hat / Fedora

RELEASE 1.2.9

- Reverted change that tried to support elderly apache rotatelogs

- Added a patch file to apply if you need to support elderly apache rotatelogs (tools/altperl/old-apache-rotatelogs.patch)

- Bug in UPDATE FUNCTIONS - wrong quoting in plpgsql function

- Add a regression test that runs UPDATE FUNCTIONS to ensure that it at least has no syntax errors

RELEASE 1.2.8

- Change to rotatelogs configuration to support older versions of Apache
log rotator

- Fix to altperl "execute script" script to pass the filename properly

- Fix to src/backend/slony1_funcs.v80.sql - comment on the right function in v8.0

- Fix to src/slonik/slonik.c - it wasn't pulling in the right version of slony1_funcs.?.sql in some cases

- Updated docs on creating releases to describe the version mismatch problem found above in slonik.c

RELEASE 1.2.7

- Add remote_listen_timeout parameter to slon.conf

This addresses the problem where a slon times out when accessing
sl_event if a node has been out of commission for a long time (several
days)

- Resolve bug #1623

In this bug, big "action lists" that need to get compressed could cause
a logging printf to blow up.  Changed the logging level so that detail
is only shown at level 4, which won't bite people by default.

- UNINSTALL NODE failures now show node # in slonik error messages

If a user ran several UNINSTALL NODE requests in a single slonik
script, and one of them broke, you'd have no ready way to tell which
node this failed on.  Added code to report the node # where it failed.

- Added test to test1 for function generate_sync_event() and make_function_strict

- Added "v81" files (for slony1_base.v81.sql, slony1_funcs.v81.sql,
xxid.v81.sql), necessary to support 8.1 "ALTER FUNCTION ... STRICT";

- Fixed quoting problem in generate_sync_event()

- Added functionality to UPDATE FUNCTIONS to make xxidin() function
STRICT; the absence of this caused postmaster to fall over when
processing MOVE SET event in PG v8.2

- Added documentation of an issue surrounding NULLABLE columns to the
log analysis chapter of the admin guide and to the UPGRADING docs.

- When you run MOVE SET, this populates sl_setsync for the moved set
  even on nodes that are not subscribed.  If, subsequent to doing this, 
  you attempt a SUBSCRIBE SET for a formerly-unsubscribed node, the
  subscription will fail right at the end when the slon tries to insert a
  new value to sl_setsync.

  The fix: DELETE from sl_setsync immediately before the INSERT.  This
  will silently blow away any 'offending' sl_setsync row.

  (As observed by Afilias staff...)

- Log shipping fix - storage of sl_setsync_offline call had a wrong
  printf type; change from %d to %s

RELEASE 1.2.6

Release 1.2.6 fixes version numbers.

RELEASE 1.2.5 

Release 1.2.5 of Slony-I has the following bug fixes over 1.2.2:

- Fixed issue with xxid C functions - these functions need to be
  defined STRICT so that NULL values don't cause the functions to
  barf.  This has been causing users of PostgreSQL 8.2 to see
  postmasters falling over.

- Several improvements to internal documentation of altperl scripts

RELEASE 1.2.2

Release 1.2.2 of Slony-I has the following bug fixes over 1.2.1:

- SGML tagging fixes to allow docs to be generated on Fedora

- Fixes to altperl scripts (init cluster, store node) so they would
  properly generate STORE PATH requests (which had broken when STORE
  LISTEN code was removed)

- If PostgreSQL version is 8.1 or greater, we can use pg_config
  sharedir. Otherwise we will resort to the default guessing mode.

- Some makefile hygenic fixes

- Added \n to a number of log requests

- Fix to UPDATE FUNCTIONS which did not consider versions 1.1.5/1.1.6
  to be members of the 1.1 stream.  The minor problem with this was
  that Slony-I tables wouldn't get altered to drop out OIDs.  The
  major problem was that the new table sl_registry wouldn't get
  created

- Removed some confusing NOTICEs concerning management of partial
  indexes on sl_log_1 and sl_log_2.

- Close file descriptors upon running slon_terminate_worker() so that
  we don't run out of file descriptors

- Added in sleep(10) requests in several places where attempts to
  access the database in the main thread fails; this means that, for
  instance, the main DB is down, the slon doesn't simply sit there
  continually attempting to reconnect, as many times per second as it
  can.

- Several fixes to RPM .spec files

- Environment fix to Win32 service

- Set escape_string_warning to off, to prevent pgsql log noise when
  replicating cross versions

- Fix memory leak: free logshipping query 

- Bug #1585 - on 8.0+, if TRUNCATE failed, indices were not being
  deactivated during SUBSCRIBE SET COPY request, greatly slowing loading
  of data.  Added a deactivation inside the exception block, so that
  indices are deactivated during the COPY no matter what.

- X-Fade noticed that UPGRADE FUNCTIONS was taking out exclusive locks
  on sl_log_1, sl_log_2, sl_seqlog, which means that doing a Slony-I
  upgrade involved imposing an application outage.

  Moved the ALTER TABLE ... WITHOUT OIDS requests for these tables to
  cleanup loops, elsewhere, so that these tables no longer need to be 
  locked as part of the upgrade process.

- Documentation changes: Need for client/server encodings to match

- Fixes to parameter handling and interpreter name for
  test_slony_state*.pl scripts

- There was an error condition where if the final line of a slon.conf
  file did not end with a \n, then:
   a) A comment on that line would be treated as a syntax error
   b) A value set on that line would be ignored
  Fixed.

RELEASE 1.2.1

Release 1.2.1 of Slony-I has the following improvements over 1.2.0:

- Added a SYNC slonik command to allow requesting a SYNC event.
  This is a more useful thing to wait for than a SUBSCRIBE SET.

- MERGE SET now refuses to be applied if a subscriber has not
  yet confirmed post-subscription events

- Added a SLEEP slonik command to allow writing code that tells
  the script to pause for some number of seconds

- Fixed a concurrency problem where if you had multiple log
  shipped nodes, the threads processing them shared a single
  file descriptor as well as other variables.

- If a child process exits with return code of 0, that means it
  *asked* to exit, presumably because configuration changed that it
  needs to reload.  In that case, there's no need to wait 10s before
  restarting the thread; we should restart the thread immediately.

  This causes operations like MOVE SET to run ~10s faster per
  subscription change.

- Added a script, tools/release_checklist.sh, which performs some of
  the release checklist checks, such as verifying that the Slony-I
  version number (e.g. - 1.2.1) is consistent across various places
  that need to reference it.

- altperl scripts have had "listen path" generation removed as that is
  handled automatically as clusters are built.

- Fixed some portability problems in tools/launch_cluster.sh

- Added a new script, tools/search_logs.sh, meant to search hourly for
  errors in slon logs and warn an administrator about them.

RELEASE 1.2.0

Release 1.2 of Slony-I has numerous improvements over previous
versions.  

Many of them should represent near-invisible enhancements that improve
how Slony-I manages replication configuration.  These include:

- A major revision of memory management to limit memory usage by slon
  daemons.  In earlier versions, slon would try to load 100 tuples
  into memory at a time.  If you have tables with Very Large bytea or
  character varying columns, this could lead to loading 100 x 50MB
  into memory, twice, doing terrible things to memory consumption.

  slon now loads tuples in, directly, only if they are less than a
  certain size, and handles those 50MB tuples individually.

- Log switching: periodically, Slony-I will switch between storing
  replication data in sl_log_1 and sl_log_2, which allows regularly
  cleaning these tables out via TRUNCATE and which prevents some data
  loss problems relating to cases where different sets originate on
  different nodes, when transaction IDs roll over the 32 bit limits.

- pg_listener is now used dramatically less than it used to be, which
  diminishes the number of dead tuples you will find in this table.

  This, along with log switching, should improve Slony-I behaviour on
  systems where long-running transactions are common.  Older versions
  of Slony-I could suffer quite badly on systems that get hit by
  long-running transactions.

- DDL scripts are broken into individual statements

  This is more a bug fix than an enhancement; it now permits DDL
  scripts to create new tables and columns, and reference them later
  in the script.

  In the past, DDL was submitted to the postmaster as a single query,
  which meant that all of them had to reference the state of
  pg_catalog as it was before the DDL ran.  So you could add as many
  columns to tables as you liked; you could NOT, then, reference those
  columns, because the query processor would discover that the new
  column didn't exist as at "before the DDL ran."

  There is now a statement parser which splits scripts into individual
  SQL statements and passes them to the database back end
  individually.

- Slony-I tables are now marked "WITHOUT OIDS" so that they do not
  consume OIDS.

  It's only particularly important for sl_log_1/sl_log_2/sl_seqlog,
  but the change has been applied to all the tables Slony-I uses.
  UPGRADE FUNCTIONS will remove OIDs from Slony-I tables in existing
  schemas, too.

- When possible (based on log switching functionality), partial
  indexes on sl_log_1 and sl_log_2 are created on a per-origin-node
  basis.  This provides the performance boost of having an easily
  recognisable index, but without the risk of having XIDs from
  different nodes mixed together in one index, where roll-over could
  Cause Problems...

These features are generally configurable, but the defaults ought to
allow improved behaviour for all but the most "Extreme Uses."

There are also numerous enhancements that are more directly visible:

- Windows support

  A group of developers has contributed changes to allow running
  Slony-I as a Windows service.

- PostgreSQL Version Compatibility Changes

  Slony-I developers have been following the 8.2 release expected in
  fall 2006; Slony-I 1.2 can be expected to work with it without
  problems.

  Compatibility with version 7.3 has been dropped; version 1.2 notably
  makes use of some array functionality that didn't exist in 7.3.  If
  you are on 7.3, you're on a REALLY OLD version of PostgreSQL, and
  really ought to upgrade.  You may use Slony-I 1.1.5 to get to a more
  modern version, and then upgrade to 1.2 as needed.

- Process structure is revised considerably; in 1.1.0, an attempt was
  made to create an internal 'watchdog' that would restart threads
  that fell over for whatever reason.

  In 1.2, this is massively revised.  The "main" slon thread should,
  as of 1.2, never fall down, which means that there should no longer
  be a need for watchdog processes to watch carefully.

  This makes slon very much less fragile than it was in earlier
  versions.  This may revise how you want to start it up...  In the
  past, slon processes tended to fall over easily, mandating having
  some form of "watchdog."  The new behaviour points more towards
  "init" / "rc.d"-like handling, where, upon boot-up, one "rc.d" script
  might start up PostgreSQL, another one starts pgpool, and a third
  (which must be invoked after PostgreSQL is started) starts up a
  slon.

- Subscribe set aggressively locks tables on the subscriber to avoid
  failures

  This may become a configurable option so that sites where they
  Really Know What They're Doing and are sure that they won't deadlock
  themselves can leave the tables more open.

  But for most users, it's really preferable to lock the tables down
  on the subscriber so that you don't get 18 hours into subscribing an
  18GB replication set, hit a deadlock, and have to start all over.
  (The slon will automatically try again; the irritation is that you
  may have been depending on that getting done by Monday morning...)

- As has been the case for fairly much each release that has been
  made, the documentation has been significantly extended.  The "admin
  guide" has been augmented and cleaned up.  

  Notable additions include a listing of "Best Practices" (due in
  great part to discoveries by the oft-unsung heroes of Afilias' Data
  Services department) and a fairly comprehensive listing of log
  messages you may expect to see in your Slony-I logs.

- A lot of fixes to the build environment (this needs to be tested on
  lots of platforms)

  One noticeable upshot of this should be that (on Unix-like systems;
  Windows(tm) appears to differ) you oughtn't need to specify a whole
  lot of --with-pg[options] on the ./configure command line. You should
  be able to get most of what's needed simply by specifying the path to
  pg_config via --with-pgconfigdir.

- slon "lag interval" option

  You can tell a node to lag behind by a particular interval of time.

    slon -l "4 hours" [and probably other options :-)] 

  will cause the slon to ignore events until they reach the age
  corresponding to the requested interval.  That way, you can hold a
  node behind by 4 hours.

  This is a potential "foot gun" as there are some cases (MOVE SET,
  FAILOVER) where events have to be coordinated across all nodes with
  near-simultaneity.

- slon "stop after event" option

  You can tell a slon to terminate itself as soon as it receives a
  certain event from a certain node.

  Just as with "lag interval," this could be a bit of a foot gun...

- slon "run program after each log shipped SYNC" option

  You can specify a program to run each time a SYNC event
  is successfully closed off.

- Bug 1538 - if there is only one node, sl_event, sl_log_1 never get
  cleared out

  Logic added to cleanupevent() to clear out old sl_event entries if
  there is just one node.  That then allows the cleanup thread to
  clear sl_log_1 etc.

- Bug 1566 - Force all replication to occur in the ISO datestyle.
  This ensures that we can apply date/timestamps regardless of the
  datestyle they were entered in.

- Force all replication to occur with standards_conforming_strings set
  to off. This ensures we can replicate a node running on 8.2 without
  extra escape chars showing up in the data.