[py-lmdb] Re: Potential bug in reporting num_readers from env.info()

  • From: Offer Sharabi <offer@xxxxxxxxxxxx>
  • To: py-lmdb@xxxxxxxxxxxxx
  • Date: Mon, 6 Apr 2015 16:42:11 -0400

Thanks David - the number will agree with the new docs :)

*MAGNE**+**I**C*

*Offer Sharabi *|* Software Developer*

magnetic.com <http://www.magnetic.com/>  | blog
<http://www.magnetic.com/magnetic-culture/>  |  t
<https://twitter.com/MagneticIs>witter <https://twitter.com/MagneticIs>  |
facebook <https://www.facebook.com/pages/Magnetic/297609126995926>  |
linkedin <http://www.linkedin.com/company/magnetic_2>  |  youtube
<http://www.youtube.com/user/MagneticRetargeting>

On Mon, Apr 6, 2015 at 4:20 PM, David Wilson <dw@xxxxxxxx> wrote:

> On Mon, Apr 06, 2015 at 03:55:44PM -0400, Offer Sharabi wrote:
>
> > while working with lmdb we have noticed a potential bug in the
> num_readers as
> > reported by the env.info() call.
>
> > This happens after some stale readers are removed. Say that 'env' is
> > an Environment instance - the number of readers under the
> > 'num_readers' key in the env.info() dictionary does not change, even
> > when env.reader_check() returns a positive number. In contrast , the
> > call to env.readers() only return the active readers as expected.
>
> Hi Offer,
>
> Thanks for reporting this, looks like a documentation bug in the
> binding. The 'numreaders' value returned by info() indicates the maximum
> number of readers that have ever been active since the lock file was
> created, it appears to be used to limit scanning of the reader table
> during begin() to the last possibly used reader slot, whereas the table
> produced by readers() only includes slots which were active at the time
> of the mdb_reader_list() call, regardless of their position in the slot
> table.
>
> I'll confirm with upstream and update the docs shortly.
>
>
> David
>
>

Other related posts: