On Oct 27, 2012, at 5:43 AM, Greg Sabino Mullane <[email protected]> wrote:
> Well, that depends on when the kid died: could be that the handles were > not created yet, or even that they are not used in that sync. As this > rolling back is just a safety measure, I think it is fine to have it > react the way you coded it. Okay, good. > For the record, this is talking about the > kid process exception handler, not the exception handler that is a customcode > :) Right. > Yes, I would be happier with that approach rather than getting the MCP > involved. I will do that today, then. >> Is `getrows` really a no-op? > > Yes. It is the obligation of customcodes to get the data themselves now. I'll rip it out. >> I really do not understand the difference between overdue and expired, >> since neither seems to have an affect on whether or why a sync is kicked. >> Are they really this similar? And useful for nothing other than a report? > > Yep: one is a warning, one is a critical. They have no effect on the sync. > We could in theory put them into a separate table, but that seems to > complicate things too much. Oh, okay. How is this? =item C<overdue> An interval specifying the amount of time after which the sync has not run that it should be considered overdue. C<check_bucardo_sync> issues a warning when a sync has not been run in this amount of time. =item C<expired> An interval specifying the amount of time after which the sync has not run that it should be considered expired. C<check_bucardo_sync> issues a critical messagewhen a sync has not been run in this amount of time. Thanks, David _______________________________________________ Bucardo-general mailing list [email protected] https://mail.endcrypt.com/mailman/listinfo/bucardo-general
