Loading...

Type: Task
Resolution: Done
Fix Version/s: WT1.3
Affects Version/s: None
Component/s: None
Labels:
- Bug

Michael, dumping relatively complex tables doesn't work because the key/value pair isn't set at the right level.

In summary, we have:

WT_CURSOR/WT_CURSOR_DUMP ->
    WT_CURSOR/WT_CURSOR_TABLE.cg_cursors[] ->
        WT_CURSOR/WT_CURSOR_DUMP ->
            WT_CURSOR

and it's only at the very bottom WT_CURSOR where WT_CURSTD_KEY/VALUE_SET are set.

When we call WT_CURSOR.get_key, it looks for WT_CURSTD_KEY/VALUE_SET in whatever is referenced by the cg_cursors[] array cursors, which are the dump cursors, not the underlying object cursors.

I'm guessing we either need to migrate WT_CURSTD_KEY/VALUE_SET up into the higher-level cursors somehow, or do our checks for WT_CURSTD_KEY/VALUE_SET being set at a lower level, but wanted to hear what you thought before I started whacking code.

Here's a chunk of Python test code that builds a table you can't dump.

    # Build a complex table with multiple files.
    def complexPopulate(self):
        name = self.uri + self.name
        self.session.create(name,
            'leaf_page_max=1024,key_format=i,value_format=SiSS,' +
            'columns=(record,column2,column3,column4,column5),' +
            'colgroups=(cgroup1,cgroup2,cgroup3,cgroup4,cgroup5,cgroup6)')
        cgname = 'colgroup:' + self.name
        self.session.create(cgname + ':cgroup1', 'columns=(column2)')
        self.session.create(cgname + ':cgroup2', 'columns=(column3)')
        self.session.create(cgname + ':cgroup3', 'columns=(column4)')
        self.session.create(cgname + ':cgroup4', 'columns=(column2,column3)')
        self.session.create(cgname + ':cgroup5', 'columns=(column3,column4)')
        self.session.create(cgname + ':cgroup6', 'columns=(column4,column5)')
        cursor = self.session.open_cursor(name, None, None)
        for i in range(0, self.nentries):
                cursor.set_key(i)
                cursor.set_value(
                    str(i) + ': abcdefghijklmnopqrstuvwxyz'[0:i%26],
                    i,
                    str(i) + ': abcdefghijklmnopqrstuvwxyz'[0:i%23],
                    str(i) + ': abcdefghijklmnopqrstuvwxyz'[0:i%18])
                cursor.insert()
        cursor.close()

Here's a long stack-trace of the cursors when WT_CURSOR.next is returning in the dump function, it shows the problem (feel free to ignore it, but I didn't want to lose it, it took me long enough to figure it out).

`
(gdb) where
#0 dump_forward (cursor=0x800eb6b00, name=0x800e2b720 "table:test_truncate")
at ../src/utilities/util_dump.c:25
~~WT-1~~ 0x000000000040220c in util_dump (session=0x800e213e0, argc=1,
argv=0x7fffffffe8b0) at ../src/utilities/util_dump.c:121
~~WT-2~~ 0x0000000000404e93 in main (argc=2, argv=0x7fffffffe8a8)
at ../src/utilities/util_main.c:121
(gdb) whatis cursor
type = WT_CURSOR *
(gdb) p *cursor
$25 = {session = 0x800e213e0, uri = 0x800e2b5e0 "table:test_truncate",
key_format = 0x800e1e17c "i", value_format = 0x800eb7240 "SiSS",
get_key = 0x800696660 <__curdump_get_key>,
get_value = 0x800696f30 <__curdump_get_value>,
set_key = 0x800696b80 <__curdump_set_key>,
set_value = 0x800697270 <__curdump_set_value>,
equals = 0x80069c470 <*cursor_equals>, next = 0x800697590 <*curdump_next>,
prev = 0x8006975d0 <*curdump_prev>, reset = 0x800697610 <*curdump_reset>,
search = 0x800697650 <__curdump_search>,
search_near = 0x800697690 <__curdump_search_near>,
insert = 0x8006976d0 <__curdump_insert>,
update = 0x800697710 <__curdump_update>,
remove = 0x800697750 <__curdump_remove>,
close = 0x800697790 <__curdump_close>,
reconfigure = 0x80069b260 <__wt_cursor_notsup>, q =

{tqe_next = 0x800eb6c40, tqe_prev = 0x800e214a8}