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

[Greg Sabino Mullane]

> This commit fixes an issue where the kid exception handler was fetching 
> all of the DBI handles and calling rollback on them. It would sometimes 
> get an `undef` back. So I added code to ignore undefs. But I fear this 
> is the wrong solution: *why* would the some of the database handles 
> become undefined?

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. For the record, this is talking about the 
kid process exception handler, not the exception handler that is a customcode :)

> I ripped out customselect here. It's gone. I am assuming that cutomname still works 
> since t/02-bctl-customname.t still exists. I just want to make sure of that.

Yes, that's fine.

> But maybe it would be better done if the child set a flag for 
> itself instead of relying on a message from the MCP?

Yes, I would be happier with that approach rather than getting the MCP involved.

> Is `getrows` really a no-op?

Yes. It is the obligation of customcodes to get the data themselves now.

> 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.

-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20121027/7ed98463/attachment.sig>