Log Message:
-----------
attached are four distinct patches, fixing some gross oversights/typos 
and removing all traces of the PostgreSQL-source requirements - as done 
in the english docs.

1. small-de-docupdate.diff - this is a resent of my last diff against 
the master-slave doc fixing two small typos

2. failover-linebreak-typos.diff - this fixes some long lines and 
contains some spelling improvments too

3. install-doc-update.diff - removes all traces of the Postgresql-source 
requirements and shortens some long lines.

4. overview-linebreakfixup.diff - this fixes the issue with the missing 
linebreaks in the german overview-doc - I'm sorry for that oversight.



Stefan

Modified Files:
--------------
    slony1-engine/doc/howto:
        slony-I-basic-mstr-slv.txt.de (r1.2 -> r1.3)
        slony-I-failover.txt.de (r1.1 -> r1.2)
        slony-I-install.txt.de (r1.3 -> r1.4)
        slony-I-overview.txt.de (r1.1 -> r1.2)

-------------- next part --------------
Index: slony-I-basic-mstr-slv.txt.de
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/howto/slony-I-basic-mstr-slv.txt.de,v
retrieving revision 1.2
retrieving revision 1.3
diff -Ldoc/howto/slony-I-basic-mstr-slv.txt.de -Ldoc/howto/slony-I-basic-mstr-slv.txt.de -u -w -r1.2 -r1.3
--- doc/howto/slony-I-basic-mstr-slv.txt.de
+++ doc/howto/slony-I-basic-mstr-slv.txt.de
@@ -57,7 +57,7 @@
 Falls pl/pgSQL bereits fr?her in der template1 Datenbank installiert wurde
 kann dieser Schritt jedoch ?bersprungen werden.
 
-createlang plpgsql -h $MASTERHOST $MASTERDBNAME
+createlang -h $MASTERHOST plpgsql $MASTERDBNAME
 
 Slony-I kopiert zum jetzigen Zeitpunkt keine Tabellendefinitionen von der
 Masterdatenbank, wenn ein Slave hinzugef?gt wird.
@@ -106,8 +106,8 @@
     # zu jedem Knoten auf jeder Seite des Clusters zu verbinden. Die Syntax
     # entspricht der von PQconnectdb in der C-API.
 	# --
-	node 1 admin conninfo 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
-	node 2 admin conninfo 'dbname=$SLAVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSER';
+	node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
+	node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSER';
 
 	#--
     # Initialisierung des ersten Knotens, die ID dieses Knotens muss 1 sein.
Index: slony-I-failover.txt.de
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/howto/slony-I-failover.txt.de,v
retrieving revision 1.1
retrieving revision 1.2
diff -Ldoc/howto/slony-I-failover.txt.de -Ldoc/howto/slony-I-failover.txt.de -u -w -r1.1 -r1.2
--- doc/howto/slony-I-failover.txt.de
+++ doc/howto/slony-I-failover.txt.de
@@ -64,20 +64,22 @@
 
   Schritt 3)
 
-    Nach der Rekonfiguration der Webapplikation (oder des pgpool D?mons)
+    Nach der Rekonfiguration der Webapplikation (oder des "pgpool"-Daemons)
     um auf die Datenbank zu verbinden, die nun auf Knoten 2 l?uft, sollte
     der Webserver neu gestartet werden.
 
-    Ausgef?hrt mittels Hilfe eines Shellskriptes, welches dieses Herunterfahren,
-    die Neukonfiguration mittels "slonik" sowie das Verschieben der Konfigurationsdaten
-    sammt anschliessendem Neustart erledigt, dauert diese Prozedure weniger als
-    zehn Sekunden.
-
-    Danach ist es m?glich, den Knoten 1 herunterzufahren und die n?tigen Wartungsarbeiten
-    vorzunehmen. Nach einem sp?teren Neustart, wird Knoten 1 erneut an der Replikation 
+    Ausgef?hrt mittels Hilfe eines Shellskriptes, welches dieses
+    Herunterfahren, die Neukonfiguration mittels "slonik" sowie das
+    Verschieben der Konfigurationsdaten sammt anschliessendem Neustart
+    automatisch erledigt, dauert diese Prozedure weniger als zehn Sekunden.
+
+    Danach ist es m?glich, den Knoten 1 herunterzufahren und die n?tigen
+    Wartungsarbeiten vorzunehmen.
+    Nach einem sp?teren Neustart, wird Knoten 1 erneut an der Replikation 
     teilnehmen und nach einiger Zeit eventuell wieder "aufholen".
-    Zu diesem Zeitpunkt wird nun die gesamte Prozedure mit vertauschten Knotenid's
-    erneut durchgef?hrt und damit die urspr?ngliche Situation wiederhergestellt.
+    Zu diesem Zeitpunkt wird nun die gesamte Prozedure mit vertauschten
+    Knotenid's erneut durchgef?hrt und damit die urspr?ngliche Situation
+    wiederhergestellt.
 
 
 Service?bernahme im Notfall
@@ -133,11 +135,12 @@
 	drop node (id = 1, event node = 2);
 
 
-Wiederinbetriebnahme von Knoten 1 nach der Ubernahme
+Wiederinbetriebnahme von Knoten 1 nach der ?bernahme
 
     Nach der ?bernahme m?ssen alle auf Knoten 1 gespeicherten Daten als
     ung?ltig in Bezug zum Rest der Knoten betrachtet werden. Aus diesem
-    Grund besteht die einzige M?glichkeit Knoten 1 wieder in Betrieb zu nehmen 
-    und erneut die Masterrolle zuzuweisen darin ihn neu zu initialisieren.
+    Grund besteht die einzige M?glichkeit Knoten 1 wieder in Betrieb zu
+    nehmen und erneut die Masterrolle zuzuweisen, darin ihn neu zu
+    initialisieren.
     Nachdem er erneut syncronisiert ist kann eine kontrollierte Dienst?bernahme
     mittels der Anfangs angefuhrten Prozedur durchgef?hrt werden.
Index: slony-I-overview.txt.de
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/howto/slony-I-overview.txt.de,v
retrieving revision 1.1
retrieving revision 1.2
diff -Ldoc/howto/slony-I-overview.txt.de -Ldoc/howto/slony-I-overview.txt.de -u -w -r1.1 -r1.2
--- doc/howto/slony-I-overview.txt.de
+++ doc/howto/slony-I-overview.txt.de
@@ -1,28 +1,54 @@
 Warum ein weiteres Replikationssystem ?
 
-Slony-I basiert auf der Grundidee eines universellen Replikationssystems welches nicht auf eine bestimmte Version des Datenbankmanagmentsystems PostgreSQL angewiesen ist. Zum dem sollte dieses Replikationssystem aktivier- bzw. deaktivierbar sein ohne einem kompletten Dump- und Restorezyklus.
-
-Was Slony-I ist:
-
-Slony-I ist ein Master-Slave - genauer gesagt ein Master-"Multiple Slave" Replikationssystem. Es unterst?tzt weiters das kaskadieren, sowie die einfache Promotion eines oder mehrerer Slaves.
-Das Entwicklungsziel f?r Slony-I besteht aus einem Master-Slave Replikationssystem mit allen n?tigen Features um grosse Datenbanken zu einer eingeschr?nkten Anzahl an Clientsystemen (Slaves) replizieren zu k?nnen.
+Slony-I basiert auf der Grundidee eines universellen Replikationssystems
+welches nicht auf eine bestimmte Version des Datenbankmanagmentsystems
+PostgreSQL angewiesen ist.
+Zudem sollte dieses Replikationssystem aktivier- bzw. deaktivierbar sein
+ohne einen kompletten Dump- und Restorezyklus zu erfordern.
+
+Was ist Slony-I:
+
+Slony-I ist ein Master-Slave - genauer gesagt ein Master-"Multiple Slave"
+Replikationssystem.
+Es unterst?tzt weiters das kaskadieren, sowie die einfache Promotion eines
+oder mehrerer Slaves.
+Das Entwicklungsziel f?r Slony-I besteht aus einem Master-Slave
+Replikationssystem mit allen n?tigen Features um grosse Datenbanken zu
+einer eingeschr?nkten Anzahl an Clientsystemen (Slaves) replizieren zu
+k?nnen.
 
 Einsatzgebiet:
 
-Aufgrund seines Designs ist Slony-I vorallem f?r den Einsatz in Rechenzentren gedacht, wo im Normalbetrieb alle Komponenten des Replikationssystems verf?gbar sind.
-
-Was Slony-I NICHT ist:
-
-Slony-I ist kein Netzwerkmanagmentsystem. Slony-I besitzt weiters keine Mechanismen um von sich aus den Ausfall eines Knotens zu erkennen, auch f?hrt Slony-I kein automatisches promoten eines Slaves zu einem Master durch.
+Aufgrund seines Designs ist Slony-I vorallem f?r den Einsatz in Rechenzentren
+gedacht, wo im Normalbetrieb alle Komponenten des Replikationssystems
+verf?gbar sind.
+
+Was ist Slony-I NICHT:
+
+Slony-I ist kein Netzwerkmanagmentsystem.
+Slony-I besitzt weiters keine eingebauten Mechanismen um von sich aus den
+Ausfall eines Knotens zu erkennen, auch f?hrt Slony-I kein automatisches
+promoten eines Slaves zu einem Master durch.
 Mit Slony-I ist zudem kein Multimasterbetrieb m?glich.
-Auch besitzt Slony-I weder die Funktionalit?t eines Connectionbrokers noch kocht es einem Kaffee und Kuchen fr?h am Morgen.
+Auch besitzt Slony-I weder die Funktionalit?t eines Connectionbrokers noch
+kocht es einem Kaffee und Kuchen fr?h am Morgen.
 
 Warum f?hrt Slony-I keine automatisches Failover durch?
 
-Generell ist Failover der Job eines Netzwerkmanagmentsystems nicht von Slony-I selbst, insbesondere da die Anforderungen, die Konfigurationen und auch die n?tigen Schritte f?r einen Failoverpfad von Einsatzgebiet zu Einsatzgebiet sehr unterschiedlich sein k?nnen.
-Hochverf?gbarkeitssysteme mit Keepalive-?berwachung, redundant ausgelegten Netzwerk- und Speicherkomponenten die die automatische fehlerfreie ?bernahme von Diensten gew?hrleisten sollen variieren je nach Hersteller und Anforderungsprofil sehr stark. 
-Diese Funktionalit?ten zu nutzen bzw. zu steuern f?llt daher eindeutig in den Bereich eines Netzwerkmanagmentsystems, genauso wie jedoch der Bereich "Datenbankreplikation" eindeutig die Dom?ne von Slony-I sein sollte! 
+Generell ist Failover der Job eines Netzwerkmanagmentsystems - nicht von
+Slony-I selbst, insbesondere da die Anforderungen, die Konfigurationen und
+auch die n?tigen Schritte f?r einen Failoverpfad von Einsatzgebiet zu
+Einsatzgebiet sehr unterschiedlich sein k?nnen.
+Hochverf?gbarkeitssysteme mit Keepalive-?berwachung, redundant ausgelegten
+Netzwerk- und Speicherkomponenten die die automatische fehlerfreie ?bernahme
+von Diensten gew?hrleisten sollen variieren je nach Hersteller und
+Anforderungsprofil sehr stark. 
+Diese Funktionalit?ten zu nutzen bzw. zu steuern f?llt daher eindeutig in
+den Bereich eines Netzwerkmanagmentsystems, genauso wie jedoch der Bereich
+"Datenbankreplikation" eindeutig die Dom?ne von Slony-I sein sollte!
 
 Bekannte Einschr?nkungen:
 
-Slony-I unterst?tzt derzeit weder die automatische Verteilung von Schema?nderungen, noch die Replikation von sogenannten "Large Objects".
+Slony-I unterst?tzt derzeit weder die automatische Verteilung von
+Schema?nderungen, noch die Replikation von sogenannten "Large Objects".
+Derzeit werden die PostgreSQL-Versionen 7.3 oder neuer unterst?tzt.
Index: slony-I-install.txt.de
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/howto/slony-I-install.txt.de,v
retrieving revision 1.3
retrieving revision 1.4
diff -Ldoc/howto/slony-I-install.txt.de -Ldoc/howto/slony-I-install.txt.de -u -w -r1.3 -r1.4
--- doc/howto/slony-I-install.txt.de
+++ doc/howto/slony-I-install.txt.de
@@ -37,21 +37,16 @@
 Ein ISO/ANSI kompatibler C-Kompiler ist erforderlich, aktuelle
 Versionen des gcc sollten problemlos funktionieren.
 
-Weiters ist eine aktuelle Version des PostgreSQL Quellcodes
-erforderlich. Da Slony-I Namespaceunterst?tzung ben?tigt ist
-PostgreSQL in der Version 7.3 die Minimalanforderung f?r eine
-erfolgreiche ?bersetzung.
+Weiters ist eine aktuelle Version des PostgreSQL Datenbanksystems mit
+installierten Server Headerdateien erforderlich.
+Da Slony-I Namespaceunterst?tzung ben?tigt ist PostgreSQL in der
+Version 7.3 die Minimalanforderung f?r eine erfolgreiche ?bersetzung.
 
 Sollte ein ben?tigtes GNU Package fehlen so ist dieses im Lieferumfang
 des jeweiligen Betriebssystems oder auch auf dem lokalen GNU
 Spiegelserver (Liste unter http://www.gnu.org/order/ftp.html) bzw.
 direkt auf ftp://ftp.gnu.org/gnu zu finden.
 
-Sollte der PostgreSQL Quellcode ben?tigt werden, so kann dieser vom
-bevorzugten PostgreSQL Spiegelserver (Liste unter
-http://www.postgresql.org/mirrors-www.html), oder mittels BitTorrent
-von http://bt.postgresql.org/ bezogen werden.
-
 Slony-I ben?tigt f?r eine erfolgreiche ?bersetzung und anschliessende
 Installation etwa 5MB an Festplattenkapazit?t.
 
@@ -72,7 +67,7 @@
 
 Kurzversion der Installation:
 
-./configure --with-pgsourcetree=<Pfad/zu/den/PostgreSQL/Quellen>
+./configure
 gmake all
 gmake install
 
@@ -81,14 +76,10 @@
 Der erste Schritt der Installationsprozedur besteht in der
 Vorbereitung des Quellcodeverzeichnisses. Diese erfolgt mit Hilfe des
 "configure" Skriptes. 
-Dieses Skript ben?tigt die Information wo sich Ihr PostgreSQl
-Quellcodeverzeichnis befindet.  Zur ?bergabe dieser Information an das
-Skript dient die --with-pgsourcetree=<Pfad/zu/den/PostgreSQL/Quellen>
-Kommandozeilenoption.
 
 Ein Beispiel:
 
-./configure --with-pgsourcetree=/usr/local/src/postgresql-7.4.3
+./configure
 
 Dieses Skript wird eine Reihe von Tests durchfuehren um verschiedene
 n?tige Informationen zu sammeln und eventuelle Eigenheiten Ihrer
@@ -119,7 +110,8 @@
 gmake install
 
 Dieses Kommando wird die n?tigen Dateien in das PostgreSQL
-Installationverzeichnis kopieren.  Beachten Sie bitte das Sie die
-n?tigen Schreibberechtigungen auf den entsprechenden Bereich besitzen.
+Installationverzeichnis kopieren, welches mittes "pg_config" ermittelt wird.
+Beachten Sie bitte das Sie die n?tigen Schreibberechtigungen auf den
+entsprechenden Bereich besitzen.
 ?blicherweise sind f?r diesen Schritt daher "root"-Berechtigungen
 erforderlich.