Below are two aspects of the presentation:

1. A text outline of the slides

2. Bill Moran's minutes (many thanks!)

Agenda
- What is Slony-I? (Hence, what are we trying to do...)
- What are some things we won't do?
- What's good; what's new for 1.2?
- Known ToDo items
- Brainstorming ideas...

What is Slony-I ?

Slony-I is an asynchronous single master to multiple slave replication
system for PostgreSQL supporting multiple database releases, cascaded
replication, and slave promotion.

Roads Not To Be Taken

- Slony-I won't be heading to become a multimaster replication system
- If someone takes a release, and uses parts of it to implement that,
that's fine
(cbb: It looks like the Skype folks have taken parts of Slony-I to
implement parts
of their partitioning system, and learned some things; I look forward to
seeing
their code release...)

- Drawing it into ?core? PostgreSQL seems undesirable, as that ties it
to specific releases
- Lack of triggers on pg_catalog tables rules out much smarter DDL behaviour
- Some things are good already
- The notion of replication via applying SYNCs seems good, something not
to change
- Performance has been improving; 1.2 should offer ?mo betta,? and there
are some ideas for beyond that

New for 1.2

- Win32 support
- slon process much less fragile
- slon process uses less RAM
- numerous performance improvements that should help behaviour with
large systems
- no more OID consumption
- less usage of resources needing vacuums

Known ToDos

- Open extra thread to start drawing data for next SYNC while present
one is being applied
- Move project to pgFoundry
- More regression tests
- Build Farm???
- Better stability --> easier to have pgAdmin support

More ToDo (which amounts to "brainstorming")
- Slonik ?EVENT PING? - akin to ping
(cbb: Gavin Sherry was quite keen on this)
- Use 2PC for safer DDL updates, ?synchronous? actions?
- Synchronizing of other sorts of objects
- Security attributes: grant,role,group,user
- Functions, aggregates, users, comments
- EXECUTE SCRIPT without locking???
- CLONE NODE ? use PITR to duplicate a node
- Promoting/demoting log shipped nodes
- Split cluster?
- Per-node STORE TRIGGER
- Have sets be ?advisory?; replicate table by table

Minutes Taken by Bill Moran
------------------------------------------------------
These are the "minutes" I took at Sunday's Slony talk. I hope I captured
everything useful that was mentioned. (Chris has added a few cbb:
comments..)

* To assure synchronization of schema: assign a version number to schema

(cbb: Darcy Cain brought this up as a method he has used; this would
presumably be an application "assurance" as opposed to something Slony-I
could do for you...)

* Is it within Slony's scope to replicate system tables: Not exactly clear
what a trigger on a DDL is?

* Statement level triggers: Call functions on GRANT/REVOKE/ALTER/etc ?
hooks into the DDL statements: This is liable to require changes to
PostgreSQL, which doesn't fit with Slony's model (breaks backwards
compatibility). Supporting new features in new versions of PostgreSQL
could break ?downgrading? capability.

(cbb: Unfortunately, the "nebulousness" of this points to this being
something that doesn't lead us to any answers as to what could be done
next.)

* Transient or temporary sets could be useful for the purpose of merging
new tables.

* There is interest in the perl tools to keep a buffer for the general
community between admin and the guts of Slony.

(cbb: Is there interest in *working on* the Perl tools? As an OSS
project, there is a need for volunteers. In the case of the Perl tools,
past volunteers have stepped away, so we kind of need new ones...)

* Error messages are awful.
(cbb: That seems to overstate it a bit, to me :-). What I heard was that
there were cases where people would get pretty raw error messages about
violations of unique constraints. It would doubtless be pretty useful to
have Slony-I detect the conditions *before* the violation so that we
could generate an error message explaining what went wrong. This has
been improving, over time; if people can point out instances that they
hit, on the mailing list, or as bug reports, that would help us find and
address "offenders" of this sort...)