Wed Nov 30 16:28:54 PST 2005
- Previous message: [Slony1-commit] By cbbrowne: BUG REPORT: invalid insert query in log shipping files (ID:
- Next message: [Slony1-commit] By cbbrowne: FEATURE REQUEST #1443 - add cluster name to "Node is
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Log Message:
-----------
Mass replacements of PostgreSQL with &postgres; so that we have
widespread consistency of handling of that...
Modified Files:
--------------
slony1-engine/doc/adminguide:
ddlchanges.sgml (r1.17 -> r1.18)
failover.sgml (r1.17 -> r1.18)
faq.sgml (r1.46 -> r1.47)
installation.sgml (r1.17 -> r1.18)
legal.sgml (r1.7 -> r1.8)
prerequisites.sgml (r1.22 -> r1.23)
slonik_ref.sgml (r1.32 -> r1.33)
slony.sgml (r1.22 -> r1.23)
startslons.sgml (r1.12 -> r1.13)
supportedplatforms.sgml (r1.4 -> r1.5)
-------------- next part --------------
Index: startslons.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/startslons.sgml,v
retrieving revision 1.12
retrieving revision 1.13
diff -Ldoc/adminguide/startslons.sgml -Ldoc/adminguide/startslons.sgml -u -w -r1.12 -r1.13
--- doc/adminguide/startslons.sgml
+++ doc/adminguide/startslons.sgml
@@ -6,15 +6,15 @@
<para>You need to run one <xref linkend="slon"> instance for each node
in a &slony1; cluster, whether you consider that node a
-<quote>master</quote> or a <quote>slave</quote>. On Windows when
+<quote>master</quote> or a <quote>slave</quote>. On &windows; when
running as a service things are slightly different. One slon service
is installed, and a seperate configuration file registered for each
-node to be serviced by that machine. The main service then manages
-the individual slons itself. Since a <command>MOVE
-SET</command> or <command>FAILOVER</command> can switch the roles of
-nodes, slon needs to be able to function for both providers and
-subscribers. It is not essential that these daemons run on any
-particular host, but there are some principles worth considering:
+node to be serviced by that machine. The main service then manages the
+individual slons itself. Since a <command>MOVE SET</command> or
+<command>FAILOVER</command> can switch the roles of nodes, slon needs
+to be able to function for both providers and subscribers. It is not
+essential that these daemons run on any particular host, but there are
+some principles worth considering:
<itemizedlist>
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.32
retrieving revision 1.33
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.32 -r1.33
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -251,7 +251,7 @@
<refentry id ="admconninfo"><refmeta><refentrytitle>ADMIN CONNINFO</refentrytitle> </refmeta>
<refnamediv><refname>ADMIN CONNINFO</refname>
- <refpurpose> preamble - identifying <productname>PostgreSQL</productname> database </refpurpose>
+ <refpurpose> preamble - identifying &postgres; database </refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
@@ -270,7 +270,7 @@
function. The user used to connect must be the special
replication superuser, as some of the actions performed later may
include operations that are strictly reserved for database
- superusers by PostgreSQL.
+ superusers by &postgres;.
</para>
<para>
@@ -420,7 +420,7 @@
<application>slonik</application> utility), while on the system
where the node database is running the shared objects of the
&slony1; system must be installed in the
- PostgreSQL library directory. Also the procedural language
+ &postgres; library directory. Also the procedural language
PL/pgSQL is assumed to already be installed in the target
database.</para>
</refsect1>
@@ -1971,12 +1971,13 @@
<para> The specified event origin must be the origin of the set.
The script file must not contain any <command>START</command> or
- <command>COMMIT TRANSACTION</command> calls. (This may change in
- PostgreSQL 8.0 once nested transactions, aka savepoints, are
- supported) In addition, non-deterministic DML statements (like
- updating a field with <function>CURRENT_TIMESTAMP</function>) must
- be avoided, since the data changes done by the script are
- explicitly not replicated. </para>
+ <command>COMMIT TRANSACTION</command> calls. (This changes
+ somewhat in &postgres; 8.0 once nested transactions, aka
+ savepoints, are supported) In addition, non-deterministic DML
+ statements (like updating a field with
+ <function>CURRENT_TIMESTAMP</function>) must be avoided, since the
+ data changes done by the script are explicitly not
+ replicated. </para>
<variablelist>
<varlistentry><term><literal> SET ID = ival </literal></term>
@@ -2029,6 +2030,16 @@
that the triggers be regenerated, otherwise they may be
inappropriate for the new form of the table schema.</para>
+ <para> Note that if you need to make reference to the cluster
+ name, you can use the token <command>@CLUSTERNAME@</command>; if
+ you need to make reference to the &slony1; namespace, you can use
+ the token <command>@NAMESPACE@</command>; both will be expanded
+ into the appropriate replacement tokens. </para>
+
+ <para> It generally seems a bad idea to use quotes in DDL scripts.
+ It appears preferable to handle that sort of thing <quote>out of
+ band.</quote> </para>
+
<para> This uses <xref linkend= "function.ddlscript-integer-text-integer">. </para>
</refsect1>
<refsect1><title>Example</title>
Index: ddlchanges.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/ddlchanges.sgml,v
retrieving revision 1.17
retrieving revision 1.18
diff -Ldoc/adminguide/ddlchanges.sgml -Ldoc/adminguide/ddlchanges.sgml -u -w -r1.17 -r1.18
--- doc/adminguide/ddlchanges.sgml
+++ doc/adminguide/ddlchanges.sgml
@@ -107,7 +107,8 @@
it into place.</para>
<para> If a particular DDL script only affects one table, it should be
-unnecessary to lock <emphasis>all</emphasis> application tables.</para></listitem>
+unnecessary to lock <emphasis>all</emphasis> application
+tables.</para></listitem>
<listitem><para> You may need to take a brief application outage in
order to ensure that your applications are not demanding locks that
Index: supportedplatforms.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/supportedplatforms.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/supportedplatforms.sgml -Ldoc/adminguide/supportedplatforms.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/supportedplatforms.sgml
+++ doc/adminguide/supportedplatforms.sgml
@@ -35,7 +35,7 @@
<entry>Intel - 32 bit</entry>
<entry>Jun 22, 2005</entry>
<entry>dvdm at truteq.co.za</entry>
- <entry>PostgreSQL Version: 7.4.6</entry>
+ <entry>&postgres; Version: 7.4.6</entry>
</row>
<row>
@@ -44,7 +44,7 @@
<entry>x86</entry>
<entry>Jun 22, 2005</entry>
<entry>dvdm at truteq.co.za</entry>
- <entry>PostgreSQL Version: 7.4.5</entry>
+ <entry>&postgres; Version: 7.4.5</entry>
</row>
<row>
@@ -53,7 +53,7 @@
<entry>x86</entry>
<entry>Jun 22, 2005</entry>
<entry>cbbrowne at ca.afilias.info</entry>
- <entry>PostgreSQL Version: 7.4.8</entry>
+ <entry>&postgres; Version: 7.4.8</entry>
</row>
<row>
@@ -62,7 +62,7 @@
<entry>x86</entry>
<entry>Jun 22, 2005</entry>
<entry>cbbrowne at ca.afilias.info</entry>
- <entry>PostgreSQL Version: 8.0.2</entry>
+ <entry>&postgres; Version: 8.0.2</entry>
</row>
<row>
@@ -71,7 +71,7 @@
<entry>x86</entry>
<entry>Jun 22, 2005</entry>
<entry>cbbrowne at ca.afilias.info</entry>
- <entry>PostgreSQL Version: 7.3.9</entry>
+ <entry>&postgres; Version: 7.3.9</entry>
</row>
<row>
@@ -80,7 +80,7 @@
<entry>PPC</entry>
<entry>Jun 22, 2005</entry>
<entry>cbbrowne at ca.afilias.info</entry>
- <entry>PostgreSQL Version: 7.4.8</entry>
+ <entry>&postgres; Version: 7.4.8</entry>
</row>
<row>
@@ -89,7 +89,7 @@
<entry>x86</entry>
<entry>Jun 22, 2005</entry>
<entry>cbbrowne at ca.afilias.info</entry>
- <entry>PostgreSQL Version: 7.4.8</entry>
+ <entry>&postgres; Version: 7.4.8</entry>
</row>
<row>
@@ -98,7 +98,7 @@
<entry>x86</entry>
<entry>Jun 22, 2005</entry>
<entry>devrim at gunduz.org</entry>
- <entry>PostgreSQL Version: 8.0.3 , docs fail to build, NAMELEN value must be increased from 44 to 100 to build the docs, or use community RPMs</entry>
+ <entry>&postgres; Version: 8.0.3 , docs fail to build, NAMELEN value must be increased from 44 to 100 to build the docs, or use community RPMs</entry>
</row>
<row>
@@ -107,7 +107,7 @@
<entry>x86</entry>
<entry>Jun 22, 2005</entry>
<entry>devrim at gunduz.org</entry>
- <entry>PostgreSQL Version: 8.0.3 , docs fail to build, NAMELEN value must be increased from 44 to 100 to build the docs, or use community RPMs</entry>
+ <entry>&postgres; Version: 8.0.3 , docs fail to build, NAMELEN value must be increased from 44 to 100 to build the docs, or use community RPMs</entry>
</row>
<row>
@@ -116,7 +116,7 @@
<entry>x86</entry>
<entry>Jun 22, 2005</entry>
<entry>devrim at gunduz.org</entry>
- <entry>PostgreSQL Version: 8.0.3 , docs fail to build, NAMELEN value must be increased from 44 to 100 to build the docs, or use community RPMs</entry>
+ <entry>&postgres; Version: 8.0.3 , docs fail to build, NAMELEN value must be increased from 44 to 100 to build the docs, or use community RPMs</entry>
</row>
<row>
@@ -125,7 +125,7 @@
<entry>x86</entry>
<entry>Jun 22, 2005</entry>
<entry>devrim at gunduz.org</entry>
- <entry>PostgreSQL Version: 8.0.3 , docs fail to build, NAMELEN value must be increased from 44 to 100 to build the docs, or use community RPMs</entry>
+ <entry>&postgres; Version: 8.0.3 , docs fail to build, NAMELEN value must be increased from 44 to 100 to build the docs, or use community RPMs</entry>
</row>
<row>
@@ -134,7 +134,7 @@
<entry>x86</entry>
<entry>Jul 14, 2005</entry>
<entry>devrim at gunduz.org</entry>
- <entry>PostgreSQL Version: 8.0.3 , docs fail to build, NAMELEN value must be increased from 44 to 100 to build the docs, or use community RPMs</entry>
+ <entry>&postgres; Version: 8.0.3 , docs fail to build, NAMELEN value must be increased from 44 to 100 to build the docs, or use community RPMs</entry>
</row>
<row>
@@ -143,7 +143,7 @@
<entry>AMD64</entry>
<entry>Jul 01, 2005</entry>
<entry>stefan at kaltenbrunner.cc </entry>
- <entry>PostgreSQL Version: 8.0.3</entry>
+ <entry>&postgres; Version: 8.0.3</entry>
</row>
<row>
@@ -152,7 +152,7 @@
<entry>Sparc64</entry>
<entry>Jul 01, 2005</entry>
<entry>stefan at kaltenbrunner.cc </entry>
- <entry>PostgreSQL Version: 8.0.3</entry>
+ <entry>&postgres; Version: 8.0.3</entry>
</row>
<row>
<entry>OpenBSD</entry>
@@ -160,7 +160,7 @@
<entry>x86</entry>
<entry>Jul 01, 2005</entry>
<entry>stefan at kaltenbrunner.cc </entry>
- <entry>PostgreSQL Version: 8.0.3</entry>
+ <entry>&postgres; Version: 8.0.3</entry>
</row>
</tbody>
Index: failover.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/failover.sgml,v
retrieving revision 1.17
retrieving revision 1.18
diff -Ldoc/adminguide/failover.sgml -Ldoc/adminguide/failover.sgml -u -w -r1.17 -r1.18
--- doc/adminguide/failover.sgml
+++ doc/adminguide/failover.sgml
@@ -135,6 +135,7 @@
now use node2 as data provider for the set. This means that after the
failover command succeeded, no node in the entire replication setup
will receive anything from node1 any more.</para>
+
</listitem>
<listitem>
@@ -143,7 +144,15 @@
node2.</para>
</listitem>
-<listitem> <para> After the failover is complete and node2 accepts
+<listitem> <para> Purge out the abandoned node </para>
+
+<para> You will find, after the failover, that there are still a full
+set of references to node 1 in <xref linkend="table.sl-node">, as well
+as in referring tables such as <xref linkend="table.sl-confirm">;
+since data in <xref linkend="table.sl-log-1"> is still present,
+&slony1; cannot immediately purge out the node. </para>
+
+<para> After the failover is complete and node2 accepts
write operations against the tables, remove all remnants of node1's
configuration information with the <xref linkend="stmtdropnode">
command:
@@ -152,6 +161,16 @@
drop node (id = 1, event node = 2);
</programlisting>
</para>
+
+<para> Supposing the failure resulted from some catastrophic failure
+of the hardware supporting node 1, there might be no
+<quote>remains</quote> left to look at. If the failure was not
+<quote>total</quote>, as might be the case if the node had to be
+abandoned due to a network communications failure, you will find that
+node 1 still <quote>imagines</quote> itself to be as it was before the
+failure. See <xref linkend="rebuildnode1"> for more details on the
+implications.</para>
+
</listitem>
</itemizedlist>
@@ -192,14 +211,26 @@
</para>
</sect2>
-<sect2><title>After Failover, Reconfiguring node1</title>
+<sect2 id="rebuildnode1"><title>After Failover, Reconfiguring
+node 1</title>
-<para> After the above failover, the data stored on node1 will rapidly
-become increasingly out of sync with the rest of the nodes, and must
-be treated as corrupt. Therefore, the only way to get node1 back and
-transfer the origin role back to it is to rebuild it from scratch as a
-subscriber, let it catch up, and then follow the switchover
-procedure.</para>
+<para> What happens to the failed node will depend somewhat on the
+nature of the catastrophe that lead to needing to fail over to another
+node. If the node had to be abandoned because of physical destruction
+of its disk storage, there will likely not be anything of interest
+left. On the other hand, a node might be abandoned due to the failure
+of a network connection, in which case the former
+<quote>provider</quote> can appear be functioning perfectly well.
+Nonetheless, once communications are restored, the fact of the
+<command>FAIL OVER</command> makes it mandatory that the failed node
+be abandoned. </para>
+
+<para> After the above failover, the data stored on node 1 will
+rapidly become increasingly out of sync with the rest of the nodes,
+and must be treated as corrupt. Therefore, the only way to get node 1
+back and transfer the origin role back to it is to rebuild it from
+scratch as a subscriber, let it catch up, and then follow the
+switchover procedure.</para>
<para> A good reason <emphasis>not</emphasis> to do this automatically
is the fact that important updates (from a
@@ -234,8 +265,8 @@
network monitoring tool. You need to have clear methods of
communicating to applications and users what database hosts are to be
used. If those methods are lacking, adding replication to the mix
-will worsen the potential for confusion, and failover will be the
-point at which there is the greatest potential for confusion. </para>
+will worsen the potential for confusion, and failover will be a point
+at which there is enormous potential for confusion. </para>
</warning>
<para> If the database is very large, it may take many hours to
Index: installation.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/installation.sgml,v
retrieving revision 1.17
retrieving revision 1.18
diff -Ldoc/adminguide/installation.sgml -Ldoc/adminguide/installation.sgml -u -w -r1.17 -r1.18
--- doc/adminguide/installation.sgml
+++ doc/adminguide/installation.sgml
@@ -2,10 +2,10 @@
<sect1 id="installation">
<title>&slony1; Installation</title>
-<para>Note for <trademark>Windows</trademark> users:
-Unless you are planning on hacking the &slony1; code, it is highly
-recommended that you download and install a prebuilt binary
-distribution and jump straight to the configuration section below.
+<para>Note for &windows; users: Unless you are planning on hacking the
+&slony1; code, it is highly recommended that you download and install
+a prebuilt binary distribution and jump straight to the configuration
+section below.
</para>
<para>You should have obtained the &slony1; source from the previous
@@ -128,7 +128,7 @@
gmake install
</command></para>
-<para>This will install files into postgresql install directory as
+<para>This will install files into the postgresql install directory as
specified by the <command>configure</command>
<option>--prefix</option> option used in the &postgres; installation.
Make sure you have appropriate permissions to write into that area.
@@ -148,8 +148,8 @@
http://developer.PostgreSQL.org/~devrim/slony . Please read <command>
CURRENT_MAINTAINER</command> file for the details of the RPMs.
Please note that the RPMs will look for RPM installation of
-PostgreSQL, so if you install PosgtgreSQL from source, you should
-manually ignore the RPM dependencies related to PostgreSQL.</para>
+&postgres;, so if you install &postgres; from source, you should
+manually ignore the RPM dependencies related to &postgres;.</para>
<para>Installing &slony1; using these RPMs is as easy as
installing any RPM.</para>
@@ -169,12 +169,12 @@
</sect2>
<sect2>
-<title> Installing the &slony1; service on <trademark>Windows</trademark></title>
+<title> Installing the &slony1; service on &windows;</title>
-<para> On <trademark>Windows</trademark> systems instead of running one
-slon daemon per node, a single slon service is installed which can then be
-controlled through the <command>Services</command> control panel applet, or
-from a command prompt using the <command>net</command> command.</para>
+<para> On &windows; systems, instead of running one slon daemon per
+node, a single slon service is installed which can then be controlled
+through the <command>Services</command> control panel applet, or from
+a command prompt using the <command>net</command> command.</para>
<screen>
C:\Program Files\PostgreSQL\8.0\bin> slon -regservice my_slon
Index: prerequisites.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/prerequisites.sgml,v
retrieving revision 1.22
retrieving revision 1.23
diff -Ldoc/adminguide/prerequisites.sgml -Ldoc/adminguide/prerequisites.sgml -u -w -r1.22 -r1.23
--- doc/adminguide/prerequisites.sgml
+++ doc/adminguide/prerequisites.sgml
@@ -8,9 +8,8 @@
this release are FreeBSD-4X-i368, FreeBSD-5X-i386, FreeBSD-5X-alpha,
OS-X-10.3, Linux-2.4X-i386 Linux-2.6X-i386 Linux-2.6X-amd64,
<trademark>Solaris</trademark>-2.8-SPARC,
-<trademark>Solaris</trademark>-2.9-SPARC, AIX 5.1,
-OpenBSD-3.5-sparc64 and <trademark>Windows</trademark> 2000, XP and
-2003 (32 bit).</para>
+<trademark>Solaris</trademark>-2.9-SPARC, AIX 5.1, OpenBSD-3.5-sparc64
+and &windows; 2000, XP and 2003 (32 bit).</para>
<sect2>
<title> &slony1; Software Dependancies</title>
@@ -79,13 +78,12 @@
</ulink> along with <ulink url="http://openjade.sourceforge.net/">
OpenJade.</ulink> </para></listitem>
-<listitem><para> On <trademark>Windows</trademark> you will also need the
-same <ulink url=
+<listitem><para> On &windows; you will also need the same <ulink url=
"http://www.postgresql.org/docs/faqs.FAQ_MINGW.html">MinGW/Msys
-Toolset</ulink> used to build PostgreSQL 8.0 and above.
-In addition you will need to install <ulink url=
-"http://sourceware.org/pthreads-win32/">pthreads-win32 2.x</ulink>.
-</para></listitem>
+Toolset</ulink> used to build &postgres; 8.0 and above. In addition
+you will need to install <ulink url=
+"http://sourceware.org/pthreads-win32/">pthreads-win32
+2.x</ulink>. </para></listitem>
</itemizedlist> </para>
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.46
retrieving revision 1.47
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.46 -r1.47
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -120,25 +120,26 @@
<question><para> <xref linkend="slon"> does not restart after
crash</para>
-<para> After an immediate stop of postgresql (simulation of system
-crash) in pg_catalog.pg_listener a tuple with
-relname='_${cluster_name}_Restart' exists. slon doesn't start because
-it thinks another process is serving the cluster on this node. What
-can I do? The tuples can't be dropped from this relation.</para>
+<para> After an immediate stop of &postgres; (simulation of system
+crash) in <envar>pg_catalog.pg_listener</envar> a tuple with <command>
+relname='_${cluster_name}_Restart'</command> exists. slon doesn't
+start because it thinks another process is serving the cluster on this
+node. What can I do? The tuples can't be dropped from this
+relation.</para>
<para> The logs claim that <blockquote><para>Another slon daemon is
serving this node already</para></blockquote></para></question>
<answer><para> The problem is that the system table
-<envar>pg_catalog.pg_listener</envar>, used by
-<productname>PostgreSQL</productname> to manage event notifications,
-contains some entries that are pointing to backends that no longer
-exist. The new <xref linkend="slon"> instance connects to the
-database, and is convinced, by the presence of these entries, that an
-old <application>slon</application> is still servicing this &slony1;
-node.</para>
+<envar>pg_catalog.pg_listener</envar>, used by &postgres; to manage
+event notifications, contains some entries that are pointing to
+backends that no longer exist. The new <xref linkend="slon"> instance
+connects to the database, and is convinced, by the presence of these
+entries, that an old <application>slon</application> is still
+servicing this &slony1; node.</para>
-<para> The <quote>trash</quote> in that table needs to be thrown away.</para>
+<para> The <quote>trash</quote> in that table needs to be thrown
+away.</para>
<para>It's handy to keep a slonik script similar to the following to
run in such cases:
@@ -161,6 +162,13 @@
<para>As of version 1.0.5, the startup process of slon looks for this
condition, and automatically cleans it up.</para>
+
+<para> As of version 8.1 of &postgres;, the functions that manipulate
+<envar>pg_listener</envar> do not support this usage, so for &slony1;
+versions after 1.1.2 (<emphasis>e.g. - </emphasis> 1.1.5), this
+<quote>interlock</quote> behaviour is handled via a new table, and the
+issue should be transparently <quote>gone.</quote> </para>
+
</answer></qandaentry>
<qandaentry>
@@ -174,8 +182,7 @@
</answer></qandaentry>
<qandaentry>
-<question><para>Slonik fails - cannot load
-<productname>PostgreSQL</productname> library -
+<question><para>Slonik fails - cannot load &postgres; library -
<command>PGRES_FATAL_ERROR load '$libdir/xxid';</command></para>
<para> When I run the sample setup script I get an error message similar
@@ -998,13 +1005,11 @@
</answer>
<answer> <para> You can monitor for this condition inside the database
-only if the <productname> PostgreSQL </productname> <filename>
-postgresql.conf </filename> parameter
-<envar>stats_command_string</envar> is set to true. If that is set,
-then you may submit the query <command> select * from pg_stat_activity
-where current_query like '%IDLE% in transaction'; </command> which
-will find relevant activity.
-</para> </answer>
+only if the &postgres; <filename> postgresql.conf </filename>
+parameter <envar>stats_command_string</envar> is set to true. If that
+is set, then you may submit the query <command> select * from
+pg_stat_activity where current_query like '%IDLE% in transaction';
+</command> which will find relevant activity. </para> </answer>
<answer> <para> You should also be able to search for <quote> idle in
transaction </quote> in the process table to find processes that are
@@ -1016,10 +1021,9 @@
pg_stat_activity </envar> may show you some query that has been
running way too long. </para> </answer>
-<answer> <para> There are plans for <productname> PostgreSQL
-</productname> to have a timeout parameter, <envar>
-open_idle_transaction_timeout </envar>, which would cause old
-transactions to time out after some period of disuse. Buggy
+<answer> <para> There are plans for &postgres; to have a timeout
+parameter, <envar> open_idle_transaction_timeout </envar>, which would
+cause old transactions to time out after some period of disuse. Buggy
connection pool logic is a common culprit for this sort of thing.
There are plans for <productname> <link linkend="pgpool"> pgpool
</link> </productname> to provide a better alternative, eventually,
@@ -1056,7 +1060,7 @@
<itemizedlist>
<listitem><para> You'll need to identify from either the slon logs, or
-the PostgreSQL database logs exactly which statement it is that is
+the &postgres; database logs exactly which statement it is that is
causing the error.</para></listitem>
<listitem><para> You need to fix the Slony-defined triggers on the
@@ -1167,12 +1171,12 @@
and load the data back in much faster than the <command>SUBSCRIBE
SET</command> runs. Why is that? </para></question>
-<answer><para> &slony1; depends on there
-being an already existant index on the primary key, and leaves all
-indexes alone whilst using the <productname>PostgreSQL</productname>
-<command>COPY</command> command to load the data. Further hurting
-performane, the <command>COPY SET</command> event starts by deleting
-the contents of tables, which potentially leaves a lot of dead tuples
+<answer><para> &slony1; depends on there being an already existant
+index on the primary key, and leaves all indexes alone whilst using
+the &postgres; <command>COPY</command> command to load the data.
+Further hurting performane, the <command>COPY SET</command> event
+starts by deleting the contents of tables, which potentially leaves a
+lot of dead tuples
</para>
<para> When you use <command>pg_dump</command> to dump the contents of
@@ -1180,11 +1184,7 @@
the very end. It is <emphasis>much</emphasis> more efficient to
create indexes against the entire table, at the end, than it is to
build up the index incrementally as each row is added to the
-table.</para>
-
-<para> Unfortunately, dropping and recreating indexes <quote>on the
-fly,</quote> as it were, has proven thorny. Doing it automatically
-hasn't been implemented. </para></answer>
+table.</para></answer>
<answer><para> If you can drop unnecessary indices while the
<command>COPY</command> takes place, that will improve performance
@@ -1192,13 +1192,11 @@
contain data that is about to be eliminated, that will improve
performance <emphasis>a lot.</emphasis> </para></answer>
-<answer><para> There is a TODO item for implementation in
-<productname>PostgreSQL</productname> that adds a new option,
-something like <option>BULKLOAD</option>, which would defer revising
-indexes until the end, and regenerating indexes in bulk. That will
-likely not be available until <productname>PostgreSQL</productname>
-8.1, but it should substantially improve performance once available.
-</para></answer>
+<answer><para> &slony1; version 1.1.5 and later versions should handle
+this automatically; it <quote>thumps</quote> on the indexes in the
+&postgres; catalog to hide them, in much the same way triggers are
+hidden, and then <quote>fixes</quote> the index pointers and reindexes
+the table. </para> </answer>
</qandaentry>
<qandaentry>
@@ -1588,7 +1586,7 @@
<para> Of course, now that you have done all of the above, it's not compatible
with standard Slony now. So you either need to implement 7.2 in a less
hackish way, or you can also hack up slony to work without schemas on
-newer versions of PostgreSQL so they can talk to each other.
+newer versions of &postgres; so they can talk to each other.
</para>
<para> Almost immediately after getting the DB upgraded from 7.2 to 7.4, we
deinstalled the hacked up Slony (by hand for the most part), and started
Index: legal.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/legal.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -Ldoc/adminguide/legal.sgml -Ldoc/adminguide/legal.sgml -u -w -r1.7 -r1.8
--- doc/adminguide/legal.sgml
+++ doc/adminguide/legal.sgml
@@ -40,7 +40,7 @@
</para>
<para> Note that <trademark>UNIX</trademark> is a registered trademark of The
- Open Group. <trademark>Windows</trademark> is a registered trademark of
+ Open Group. &windows; is a registered trademark of
Microsoft Corporation in the United States and other countries.
<trademark>Solaris</trademark> is a registered trademark of Sun Microsystems,
Inc. <trademark>Linux</trademark> is a trademark of Linus Torvalds.
Index: slony.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slony.sgml,v
retrieving revision 1.22
retrieving revision 1.23
diff -Ldoc/adminguide/slony.sgml -Ldoc/adminguide/slony.sgml -u -w -r1.22 -r1.23
--- doc/adminguide/slony.sgml
+++ doc/adminguide/slony.sgml
@@ -8,6 +8,7 @@
<!entity reference SYSTEM "reference.sgml">
<!ENTITY slony1 "<PRODUCTNAME>Slony-I</PRODUCTNAME>">
<!ENTITY postgres "<PRODUCTNAME>PostgreSQL</PRODUCTNAME>">
+ <!ENTITY windows "<trademark>Windows</trademark>">
]>
<book id="slony">
- Previous message: [Slony1-commit] By cbbrowne: BUG REPORT: invalid insert query in log shipping files (ID:
- Next message: [Slony1-commit] By cbbrowne: FEATURE REQUEST #1443 - add cluster name to "Node is
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list