> 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 [email protected] End Point Corporation PGP Key: 0x14964AC8
pgpOgQ4G51OHb.pgp
Description: PGP signature
_______________________________________________ Bucardo-general mailing list [email protected] https://mail.endcrypt.com/mailman/listinfo/bucardo-general
