Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-2030

Reverse cursor walk seems to look at deleted items

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Works as Designed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      I was trying to manually check the number of items in the oplog just after calling truncate on it and did this:

              Cursor cursor(txn, *this, /*forward=*/false);
              int i = 0;
              while (cursor.next())
                  ++i;
              log() << "Manual recount: " << i;
      

      But it counts (and walks) the items that I just truncated, not the ones that remain. If I change forward to true, it seems to work fine.
      Mathias pointed out that we're now doing some sort of caching in WT on truncate - possibly that's not taking proper account of forward vs reverse cursors?

      in "class WiredTigerRecordStore::Cursor" next() method, AFAICS, reverseCappedInitialSeekPoint.isNull() is true, so we skip the whole of the upper chunk of code, then in the next section:

             if (mustAdvance) {
                  // Nothing after the next line can throw WCEs.
                  // Note that an unpositioned (or eof) WT_CURSOR returns the first/last entry in the
                  // table when you call next/prev.
                  int advanceRet = WT_OP_CHECK(_forward ? c->next(c) : c->prev(c));
                  PRINT(advanceRet);
                  if (advanceRet == WT_NOTFOUND) {
                      _eof = true;
                      return {};
                  }
                  invariantWTOK(advanceRet);
              }
      

      that added PRINT(advanceRet) gives zero, and the id it ends up picking up is the last truncated record, ie if I did truncate to xxxxx0005, it starts from xxxxx0004 and works backwards to xxxxx0003, etc.

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            martin.bligh Martin Bligh
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: