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

Search and search_near are behaving differently for implicit FLCS records

    • Type: Icon: Bug Bug
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Storage Engines
    • StorEng - Defined Pipeline

      For FLCS, we expect search_near and search to behave the same way for implicit records. For example, if we have the following records:

      1 <some_value>
      2 <some_value>
      ... gap ...
      10 <some_value>
      

      Doing a search or search_near on a record that is part of the gap, we should find the key but return a value of 0 that shows the record is implicit / deleted.

      The following diff exposes a bug:

      diff --git a/test/suite/test_bug001.py b/test/suite/test_bug001.py
      index af43a5ee4..bb47ad079 100644
      --- a/test/suite/test_bug001.py
      +++ b/test/suite/test_bug001.py
      @@ -57,9 +57,13 @@ class test_bug001(wttest.WiredTigerTestCase):
               for i in range(0, 5):
                   self.assertEqual(cursor[60 + i], 0x00)
       
      +        # The test passes after re-opening the connection.
      +        # self.reopen_conn()
      +        # cursor = self.session.open_cursor(uri, None)
      +
               # Check cursor next inside trailing implicit keys.
               cursor.set_key(60)
      -        self.assertEqual(cursor.search(), 0)
      +        self.assertEqual(cursor.search_near(), 0)
               for i in range(0, 5):
                   self.assertEqual(cursor.get_key(), 60 + i)
                   self.assertEqual(cursor.get_value(), 0x00)
      

      The search_near returns 1 instead of 0 and positions itself on the next valid record. If the connection is re-opened and everything is written to disk, search_near does find the implicit record.

            Assignee:
            backlog-server-storage-engines [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            etienne.petrel@mongodb.com Etienne Petrel
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: