Mon Oct 22 13:47:50 PDT 2007
- Previous message: [Slony1-commit] slony1-engine/src/slon remote_worker.c
- Next message: [Slony1-commit] slony1-engine/doc/adminguide slonik_ref.sgml
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Update of /home/cvsd/slony1/slony1-engine/doc/adminguide In directory main.slony.info:/tmp/cvs-serv19930 Modified Files: Tag: REL_1_2_STABLE loganalysis.sgml Log Message: Document new case that comes up with log shipping where fighting over access to log numbering can lead to a serialization error. Index: loganalysis.sgml =================================================================== RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/loganalysis.sgml,v retrieving revision 1.4.2.4 retrieving revision 1.4.2.5 diff -C2 -d -r1.4.2.4 -r1.4.2.5 *** loganalysis.sgml 6 Jun 2007 22:17:10 -0000 1.4.2.4 --- loganalysis.sgml 22 Oct 2007 20:47:48 -0000 1.4.2.5 *************** *** 213,216 **** --- 213,226 ---- <para> Probably means that we just filled up a filesystem... </para></listitem> + + <listitem><para> <command>ERROR remoteWorkerThread_%d: "update "_slony_regress1".sl_archive_counter set ac_num = ac_num + 1, ac_timestamp = CURRENT_TIMESTAMP; select ac_num, ac_timestamp from "_slony_regress1".sl_archive_counter; " PGRES_FATAL_ERROR ERROR: could not serialize access due to concurrent update</command> </para> + + <para> This may occasionally occur when using logshipping; this will + typically happen if there are 3 or more nodes, and there is an attempt + to concurrently process events sourced from different nodes. This + does not represent any serious problem; &slony1; will retry the event + which failed without the need for administrative intervention. </para> + </listitem> + </itemizedlist> </sect3>
- Previous message: [Slony1-commit] slony1-engine/src/slon remote_worker.c
- Next message: [Slony1-commit] slony1-engine/doc/adminguide slonik_ref.sgml
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list