Wed Nov 9 17:11:32 PST 2005
- Previous message: [Slony1-commit] By wieck: Use a new table sl_nodelock to guard against concurrent slon
- Next message: [Slony1-commit] By cbbrowne: Add mention in SET ADD TABLE that the table ID number needs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Log Message:
-----------
Note (per Vivek Khera) that LOCK SET waits for old transactions
to complete on the origin node, which may take a while...
Modified Files:
--------------
slony1-engine/doc/adminguide:
slonik_ref.sgml (r1.30 -> r1.31)
-------------- next part --------------
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.30
retrieving revision 1.31
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.30 -r1.31
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -1728,7 +1728,16 @@
<para> Note that this is a <link linkend="locking"> locking
operation, </link> which means that it can get stuck behind other
- database activity.
+ database activity.</para>
+
+ <para> The operation waits for transaction IDs to advance in order
+ that data is not missed on the new origin. Thus, if you have
+ long-running transactions running on the source node, this
+ operation will wait for those transactions to complete.
+ Unfortunately, if you have another database on the same postmaster
+ as the origin node, long running transactions on that database
+ will also be considered even though they are essentially
+ independent.
<variablelist>
<varlistentry><term><literal> ID = ival </literal></term>
- Previous message: [Slony1-commit] By wieck: Use a new table sl_nodelock to guard against concurrent slon
- Next message: [Slony1-commit] By cbbrowne: Add mention in SET ADD TABLE that the table ID number needs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list