Log Message:
-----------
Added documentation about how the slony user needs to not only be a
PostgreSQL "superuser" but to also have system table update privileges.

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        faq.sgml (r1.17 -> r1.18)
        prerequisites.sgml (r1.10 -> r1.11)

-------------- next part --------------
Index: prerequisites.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/prerequisites.sgml,v
retrieving revision 1.10
retrieving revision 1.11
diff -Ldoc/adminguide/prerequisites.sgml -Ldoc/adminguide/prerequisites.sgml -u -w -r1.10 -r1.11
--- doc/adminguide/prerequisites.sgml
+++ doc/adminguide/prerequisites.sgml
@@ -173,8 +173,9 @@
 <para> Note that <application>slonik</application> and the
 <application>slon</application> instances need no special connections
 or protocols to communicate with one another; they merely need access
-to the &postgres; databases, connecting as a
-<quote>superuser</quote>.</para>
+to the &postgres; databases, connecting as a <quote>superuser</quote>
+<link linkend="morethansuper">that has the ability to update system
+tables.</link></para>
 
 <para> An implication of this communications model is that the entire
 extended network in which a &slony1; cluster operates must be able to
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.17
retrieving revision 1.18
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.17 -r1.18
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -1191,6 +1191,46 @@
 abandoning the origin node as being corrupted.  </para></answer>
 </qandaentry>
 
+<qandaentry id="morethansuper">
+<question> <para> I created a <quote>superuser</quote> account,
+<command>slony</command>, to run replication activities.  As
+suggested, I set it up as a superuser, via the following query: 
+<command>
+update pg_shadow set usesuper = 't' where usename in ('slony',
+'molly', 'dumpy');
+</command>
+(that command also deals with other users I set up to run vacuums and
+backups).
+
+<para> Unfortunately, I ran into a problem the next time I subscribed
+to a new set.
+
+<programlisting>
+DEBUG1 copy_set 28661
+DEBUG1 remoteWorkerThread_1: connected to provider DB
+DEBUG2 remoteWorkerThread_78: forward confirm 1,594436 received by 78
+DEBUG2 remoteWorkerThread_1: copy table public.billing_discount
+ERROR  remoteWorkerThread_1: "select "_mycluster".setAddTable_int(28661, 51, 'public.billing_discount', 'billing_discount_pkey', 'Table public.billing_discount with candidate primary key billing_discount_pkey'); " PGRES_FATAL_ERROR ERROR:  permission denied for relation pg_class
+CONTEXT:  PL/pgSQL function "altertableforreplication" line 23 at select into variables
+PL/pgSQL function "setaddtable_int" line 76 at perform
+WARN   remoteWorkerThread_1: data copy for set 28661 failed - sleep 60 seconds
+</programlisting>
+
+<para> This continues to fail, over and over, until I restarted the
+<application>slon</application> to connect as
+<command>postgres</command> instead.</para>
+</question>
+
+<answer><para> The problem is fairly self-evident; permission is being
+denied on the system table, <envar>pg_class</envar>.</para></answer>
+
+<answer><para> The <quote>fix</fix> is thus:
+<programlisting>
+update pg_shadow set usesuper = 't', usecatupd='t' where usename = 'slony';
+</programlisting>
+</answer>
+</qandaentry>
+
 </qandaset>
 
 <!-- Keep this comment at the end of the file Local variables: