[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