[Bucardo-general] Commits I'm Not Sure About

[David E. Wheeler]

On Oct 27, 2012, at 5:43 AM, Greg Sabino Mullane <greg at endpoint.com> 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