Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Done
-
WT2.6.1, WT2.7.0
-
None
-
None
Description
Hi!
We found that WT_CURSOR->search_near() positions on wrong key after search for huge key in column-store table.
I'll attach test and DB, test is supposed to be run from examples/c/ directory of WiredTiger (it has hardcoded path to snappy compressor).
$ ./col-store-search
|
search for key = 0xffffffffffffffff
|
exact = -1, key = 0x30000000002
|
$ ../../wt -h col-store-search.db/ -C 'extensions=(../../ext/compressors/snappy/.libs/libwiredtiger_snappy.so)' dump colgroup:InstrumentStatus-2016-03-11:ts
|
WiredTiger Dump (WiredTiger Version 2.7.0)
|
Format=print
|
Header
|
colgroup:InstrumentStatus-2016-03-11:ts
|
allocation_size=4KB,app_metadata=,block_allocation=best,block_compressor=,cache_resident=0,checksum=uncompressed,colgroups=,collator=,columns=(ts),dictionary=0,encryption=(keyid=,name=),exclusive=0,extractor=,format=btree,huffman_key=,huffman_value=,immutable=0,internal_item_max=0,internal_key_max=0,internal_key_truncate=,internal_page_max=4KB,key_format=u,key_gap=10,leaf_item_max=0,leaf_key_max=0,leaf_page_max=32KB,leaf_value_max=0,log=(enabled=),lsm=(auto_throttle=,bloom=,bloom_bit_count=16,bloom_config=,bloom_hash_count=8,bloom_oldest=0,chunk_count_limit=0,chunk_max=5GB,chunk_size=10MB,merge_max=15,merge_min=0),memory_page_max=5MB,os_cache_dirty_max=0,os_cache_max=0,prefix_compression=0,prefix_compression_min=4,source="file:InstrumentStatus-2016-03-11_ts.wt",split_deepen_min_child=0,split_deepen_per_child=0,split_pct=75,type=file,value_format=u
|
Data
|
1
|
\e5\08\f0\13\02\a4
|
2
|
\e5\08\f0\13,\1f
|
3
|
\e5\08\f0\13-Z
|
1099511627777
|
\e5\08\f0\138\0e
|
1099511627778
|
\e5\08\f0\13BK
|
1099511627779
|
\e5\08\f0\13C~
|
2199023255553
|
\e5\08\f0\13F\7f
|
2199023255554
|
\e5\08\f0\13Q\f3
|
2199023255555
|
\e5\08\f0\13T\80
|
3298534883329
|
\e5\08\f0\13Z\f3
|
3298534883330
|
\e5\08\f0\13c\0a
|
3298534883331
|
\e5\08\f0\13d\19
|
$ printf "%x\n" 3298534883331
|
30000000003
|
I.e. one can see that the last key is 0x30000000003 while after WT_CURSOR->search_near() we're on 0x30000000002
Thanks!
Attachments
Issue Links
- is depended on by
-
SERVER-23140 WiredTiger changes for MongoDB 3.3.4
-
- Closed
-