From b249e220e2e9d172b49a3a9f95153035e338640a Mon Sep 17 00:00:00 2001 From: kanoi Date: Fri, 21 Aug 2015 12:19:43 +1000 Subject: [PATCH] ckdb - update reload comment - we reload everything --- src/ckdb.c | 25 +------------------------ 1 file changed, 1 insertion(+), 24 deletions(-) diff --git a/src/ckdb.c b/src/ckdb.c index 263b4b70..df788315 100644 --- a/src/ckdb.c +++ b/src/ckdb.c @@ -36,30 +36,7 @@ * much larger DB tables so that ckdb is effectively ready for messages * almost immediately * The first ckpool message allows us to know where ckpool is up to - * in the CCLs and thus where to stop processing the CCLs to stay in - * sync with ckpool - * If ckpool isn't running, then the reload will complete at the end of - * the last CCL file, however if the 1st message arrives from ckpool while - * processing the CCLs, that will mark the point where to stop processing - * but can also produce a fatal error at the end of processing, reporting - * the ckpool message, if the message was not found in the CCL processing - * after the message was received - * This can be caused by two circumstances: - * 1) the disk had not yet written it to the CCL when ckdb read EOF and - * ckpool was started at about the same time as the reload completed. - * This can be seen if the message displayed in the fatal error IS NOT - * in ckdb's message logfile. - * A ckdb restart will resolve this - * 2) ckpool was started at the time of the end of the reload, but the - * message was written to disk and found in the CCL before it was - * processed in the message queue. - * This can be seen if the message displayed in the fatal error IS in - * ckdb's message logfile and means the messages after it in ckdb's - * message logfile have already been processed. - * Again, a ckdb restart will resolve this - * In both the above (very rare) cases, if ckdb was to continue running, - * it would break the synchronisation and could cause DB problems, so - * ckdb aborting and needing a complete restart resolves it + * in the CCLs - see reload_from() for how this is handled * The users table, required for the authorise messages, is always updated * immediately */