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