Here is a fix for a problem reported against the standby replicas. In
that environment, it is possible that all the data in the replicas recoverable through the public api are identical, while the actual on-disc representation differs. This bug can be boiled down to doing the following in "standard" ZODB: 1. undoLog() 2. pack() 3. transactionalUndo() Previously, undoLog() encoded the file position in the 'id' key of the undo record, but of course the pack() breaks that file position. We fix this by encoding the oid of an object touched in the transaction instead. That way, transactionalUndo() can start at the current revision of the object, and scan back until it can find a transaction with a matching id to the one we're undoing. This approach breaks when the transaction we're undoing doesn't touch any objects, e.g. is an abortVersion() or commitVersion(). By edict, that's a non-requirement for now. We could fix that by doing a more expensive binary search for the matching transaction. WIBNI we had an index from tids to file positions? :)
Showing
Please register or sign in to comment