[Zope] errors in zodb after packing

[Paul Winkler]

apologies for the cross-post, i've set reply-to to zodb-dev@zope.org.

I'm forwarding this to zodb-dev, but you really should join it at least
temporarily if you want to discuss further.


On Wed, Apr 16, 2003 at 09:00:27AM +0200, Luca Olivetti wrote:
> Right after packing I have an error like this two or three times a week 
> (I pack daily):
> 
> 103620137 object serialno 0x034ae17b8d66f399 does not matchtransaction 
> id 0x034c44e302d59b5d
> 
> I know it's after packing because I run fstest before and after (this 
> problem has been bugging me for a while).
> 
> This is with zope 2.6.1
> 
> To recover this error I have to use 2.6.0 fsrecover that gives me a file 
>  with the same size but with no errors. 2.6.1 fsrecover doesn't work at 
> all. Everything seems to work fine though, even if I don't fsrecover the 
> database (at least my user aren't complaining).
> I reported this problem before and it was suggested to me to report it 
> in the zodb mailing list, but I'm not subscribed to that list.
> Am I the only one seeing this problem? Should I worry?

There is a serious known problem with filestorage packing on teh zodb-dev list.
http://mail.zope.org/pipermail/zodb-dev/2003-April/004807.html
http://collector.zope.org/Zope/875
*BUT* i'm not sure if this is your same error.
nobody mentioned transaction ID mismatch. Does collector #875 cause
transaction ID mismatches?

There is also a known problem with fsrecover.py from 2.6.1:
http://mail.zope.org/pipermail/zodb-dev/2003-March/004594.html

IMHO these are critical problems and warrant a 2.6.2 release
as soon as solutions are found and tested. 

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's SQUID BEGGAR!
(random hero from isometric.spaceninja.com)