Displaying 3 results from an estimated 3 matches for "open_nearby_postlist".
2017 Jul 31
2
Segmentation fault in matcher/queryoptimiser
...atabases that
fail on reading the `hint` field in the`QueryOptimiser`class [1].
We'd appreciate any hints on how to fix this. I've written up our
findings and solution attempts below. Should we post this on trac?
Our findings so far
================
In a core dump we see that calling the `open_nearby_postlist` function
on the `hint` variable [2] falls of a cliff, resulting in a segfault:
(gdb) bt 2
#0 0x000000000001eaa1 in ?? ()
#1 0x00007fa19d09231f in LocalSubMatch::open_post_list
(this=0x13527d0, term=..., wqf=1, factor=1,
need_positions=<optimized out>, in_synonym=&l...
2020 Aug 23
2
MultiDatabase shard count limitations
...LeafPostList::get_weight
0.02% script/public-i libxapian.so.30.8.0 [.] Xapian::Internal::intrusive_ptr<GlassDatabase const>::~intrusive_ptr
0.02% script/public-i libxapian.so.30.8.0 [.] GlassPostList::skip_to
0.02% script/public-i libxapian.so.30.8.0 [.] GlassPostList::open_nearby_postlist
0.02% script/public-i libxapian.so.30.8.0 [.] OrPostList::get_termfreq_min
0.02% perl perl [.] S_study_chunk.constprop.33
0.02% perl ld-2.28.so [.] _dl_map_object_from_fd
0.02% perl perl [.] Perl...
2020 Aug 21
2
MultiDatabase shard count limitations
Going back to the "prioritizing aggregated DBs" thread from
February 2020, I've got 390 Xapian shards for 130 public inboxes
I want to search against(*). There's more on the horizon (we're
expecting tens of thousands of public inboxes).
After bumping RLIMIT_NOFILE and running ->add_database a bunch,
the actual queries seem to be taking ~30s (not good :x).
Now I'm