[ZODB-Dev] Relstorage pack problems

[Santi Camps]

On Mon, Jan 19, 2009 at 8:22 PM, Shane Hathaway <shane at hathawaymix.org> wrote:
> Santi Camps wrote:
>> We've been using RelStorage 1.1.c1 in production environments over
>> postgresql 8.1 for some time.   It has been working really fine, but
>> yesterday we have a big problem packing a relstorage zodb mounted as a
>> zope mount point.
>
> I'm guessing that your mounted object is not attached to the root of the
> mounted database.  In that situation, both RelStorage and FileStorage
> will pack away practically everything in the mounted database, because
> from the viewpoint of the mounted database, the disconnected object is
> unreachable and thus garbage.
>
> A quick workaround is to disable garbage collection in zope.conf; then
> you can pack without losing any objects at all.  A proper fix would be
> to make the mounted object reachable from the mounted database root.  I
> believe the Zope 2 support for mounted databases does this
> automatically, but it's possible that Zope 3 takes an unwise shortcut.
>

Sorry, I miss to say we are using Zope 2.9.4, and that mounted object
is already reachable from the mounted database root (adding a ZODB
mount point to the root thought ZMI).

Although, the resultant database, after pack, has a big size.  So, not
all was deleted, but seems the root object not to be found.

We are using the same method on a lot of databases and has been
working fine for a long time, until this case.  I know it's very
difficult to say what happened, but I've reported the case because
perhaps it's possible to take some measures in order to avoid data
loss while packing.  I don't know a lot about ZODB, but
DirectoryStorage, for instance, don't delete objects immediately, but
uses a 'deleted' mark and don't remove them until X days (X configured
in the settings).  I love this caution of DirectoryStorage, but I like
all the other of RelStorage :-)

If you want we make any kind of test with our databases, It will be a pleasure

Thanks a lot for your help
-- 
Santi Camps (Earcon S.L.)
http://www.earcon.com
http://www.kmkey.com