[Date Prev][Date Next] [Chronological] [Thread] [Top]

Issue with mdb_cursor_del in MDB_DUPSORT databases



Hi Howard,

I've now switched the database to use MDB_DUPSORT and found what seems to be another issue to do with invalid data being returned after mdb_cursor_del. The following code shows the behaviour against a database that I can provide you with if you need:

        rc = mdb_cursor_open(txn, dbi, &cursor);
        char seek[] = "ku.oc.repmulp\t";
        key.mv_size = sizeof(seek);
        key.mv_data = &seek;
        mdb_cursor_get(cursor, &key, &data, MDB_SET_RANGE);
        for( i = 0; i < 15; i++ ) {
            mdb_cursor_del( cursor, MDB_NODUPDATA );
            data.mv_size = 0;
            key.mv_size = 0;
            mdb_cursor_get( cursor, &key, &data,
                //MDB_NEXT
                MDB_GET_CURRENT
                );

            if( key.mv_size == 0 )
                printf("WARNING 0 SIZE KEY\n");
            else
printf("KEY OK: %d: %.*s\n", key.mv_size, key.mv_size, key.mv_data);
            if( data.mv_size == 0 )
                printf("WARNING 0 SIZE DATA\n");
            else
printf("DATA OK: %d: %.*s\n", data.mv_size, data.mv_size, data.mv_data);
        }
        mdb_txn_abort(txn);

If you run as-is it seems that if the cursor points at a record with multiple entries, the data is not updated. If however the mdb_cursor_del line is commented and mdb_cursor_get changed to use MDB_NEXT the output is as expected with multiple entries. Here is sample output with get-only:

KEY OK: 16: ku.oc.repmulp       MX
DATA OK: 40: 4160598    300     0 primary.mail.plumper.co.uk
KEY OK: 16: ku.oc.repmulp       MX
DATA OK: 37: 4160598    300     10 cerebellum.david14.com
KEY OK: 16: ku.oc.repmulp       MX
DATA OK: 46: 4160598    300     20 secondary-mail.mailhoster.co.uk
KEY OK: 16: ku.oc.repmulp       NS
DATA OK: 30: 4160598    300     ns1.xcalibre.co.uk
KEY OK: 16: ku.oc.repmulp       NS
DATA OK: 30: 4160598    300     ns2.xcalibre.co.uk
KEY OK: 21: ku.oc.repmulp.05pot A
DATA OK: 29: 4160598    86400   212.159.180.202
KEY OK: 22: ku.oc.repmulp.05pot MX
DATA OK: 40: 4160598    300     0 primary.mail.plumper.co.uk
KEY OK: 22: ku.oc.repmulp.05pot MX
DATA OK: 37: 4160598    300     10 cerebellum.david14.com
KEY OK: 22: ku.oc.repmulp.05pot MX
DATA OK: 46: 4160598    300     20 secondary-mail.mailhoster.co.uk

And here with mdb_cursor_del:
KEY OK: 16: ku.oc.repmulp       MX
WARNING 0 SIZE DATA
KEY OK: 16: ku.oc.repmulp       NS
WARNING 0 SIZE DATA
KEY OK: 21: ku.oc.repmulp.05pot A
DATA OK: 29: 4160598    86400   212.159.180.202
KEY OK: 22: ku.oc.repmulp.05pot MX
WARNING 0 SIZE DATA
KEY OK: 25: ku.oc.repmulp.05pot.www     A
DATA OK: 29: 4160598    86400   212.159.180.202
KEY OK: 20: ku.oc.repmulp.3pop  A
DATA OK: 29: 4160598    86400   212.159.180.202

Behaviour seems to be the same regardless of whether I use MDB_NODUPDATA or 0 as the mdb_cursor_del flag (ie 0 length data returned and all duplicate entries deleted)

Thanks,

Mark