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: > > #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. According to BDB error: BDB0056 DB->cursor: DB_READ_COMMITTED, DB_READ_UNCOMMITTED and DB_RMW 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 DB_RDONLY. > 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 http://qboosh.pl/ _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en