There's an endless row of bugs where BDB environment getting corrupted, some
of which have been BDB bugs (several found just in the last couple of years)
that have been patched in Fedora/RHEL libdb but upstream BDB 5.x does not have,
dunno about 6.x but there you run into the licensing side. So if you're running
upstream BDB 5.x on Mac, you'll want to a check those Fedora/RHEL patches to
libdb. Some of the more exotic bugs have been kernel VM, virtualization and
whatnot.
Fsync is only disabled on the first open of a newly created database (ie during
fresh install), (iirc) never on existing database unless forced via
configuration.
After adding the .dbenv.lock to serialize rpmdb open and close a few years ago
(to work around what seems like a BDB bug), I haven't been able to reproduce
environment corruption from parallel access in my setup but doesn't mean it
doesn't happen in some other setup, version mix and whoknowswhat.
One possible workaround is to force use of private environment. That also means
practically no locking, but at least it means queries will not corrupt anything
(however queries themselves could return garbage if run in middle of
write-operation). That's what happens if you run queries as non-privileged
user, but since you can control permissions with sandboxing you can achieve the
same by disallowing open of /var/lib/rpm/.dbenv.lock, which causes rpm to fall
back to a private environment - meaning it wont open, much less write to those
__db.* files.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307753745
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
