>
> I’m sure your analysis is correct …
>
> … meanwhile what was the core issue? What problem are you trying to solve?
>
> Issues relating to whether a cursor COULD (or SHOULD) read uncommitted data
> are quite complex, including whether the flags are inherited from the
> database open
> and applied to the cursor open. RPM code doesn’t directly set either of those
> flags,
> and likely Just Works with either setting depending if/when correctly
> configured.
>
As you probably know, these 3 lines are the cause of the problem:
#define FMASK (DB_READ_UNCOMMITTED|DB_READ_COMMITTED)
flags |= (dbi->dbi_oflags & FMASK);
#undef FMASK
As near as I can recall, dbi_oflags on some older version of Berekely DB
was the place to set the flags. BerkeleyDB has evolved to finer
grained control of flags since then.
Dropping DB_READ_COMMITTED in FMASK prevents DB_READONLY from
propagating.
But the then the issue of whether “read_committed” and “read_uncommitted”
read from macros makes any sense at all.
I’ll try to sort the issue before rpm-5.4.18.
73 de Jeff
_______________________________________________
pld-devel-en mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
