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? Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
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)
On Wed, 2003-04-16 at 10:00, Paul Winkler wrote:
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.
There is a growing collection of important ZODB bugs to fix in Zope 2.6.2. I'd like to wrap up the bug fixing soon and prepare a release. I'm currently working on a new pack implementation to fix the reported bugs and a few soon-to-be-reported bugs. Since this is a rewrite of a fairly involved operation, I'm not sure if this pack fix will make it into a bugfix release. We'll need to evaluate the trade-offs once the code is finished. Jeremy
Luca Olivetti wrote at 2003-4-16 09:00 +0200:
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).
It indicates a packing bug.
.... Everything seems to work fine though, even if I don't fsrecover the database (at least my user aren't complaining).
The redundance between the transaction and the object serial is not essential for use the object pickle. Dieter
participants (4)
-
Dieter Maurer -
Jeremy Hylton -
Luca Olivetti -
Paul Winkler