pld rpm 5.4.17

Jakub Bogusz qboosh at
Sat Feb 25 08:12:34 CET 2017

On Fri, Feb 24, 2017 at 08:10:33PM -0500, Jeffrey Johnson wrote:
> > I???m sure your analysis is correct ???
> > 
> > ??? meanwhile what was the core issue? What problem are you trying to solve?

This one - inability to query database without write access to db environment
(i.e. from plain user account).

> > 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.

I didn't set db_read_uncommitted or db_read_committed in *dbi* macros.
DB_RDONLY is set by db3open() if there is no write access to dbenv
(access(dbhome, W_OK) == -1).

> As you probably know, these 3 lines are the cause of the problem:
>         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.

According to BDB error:
require locking
error: db3copen:db3.c:1470: db->cursor(22): Invalid argument

DB_READ_COMMITTED (as well as DB_READ_UNCOMMITTED) requires locking,
i.e. write access to dbenv, so it cannot be used with database open with

> But the then the issue of whether ???read_committed??? and ???read_uncommitted???
> read from macros makes any sense at all.

Yes, just dropping propagating DB_RDONLY(==DB_READ_COMMITTED) from dbi_oflags
to DB->cursor flags disables passing read_committed from *dbi* macros.
To support this option, it must be passed in some other way, not
dbi_oflags used for DB->open (nb. for DB->open it would mean... DB_RDONLY).

Jakub Bogusz

More information about the pld-devel-en mailing list