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

filling in implicitly created fixed-length records



    • Type: Task
    • Status: Closed
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: WT1.0
    • Component/s: None
    • Labels:


      Michael, there's something that's been on my cleanup list for awhile.

      If you create a record past end-of-table in a fixed-length file, you implicitly create a bunch of records, all with the value of 0 because there's no out-of-band "deleted" value. However, whether or not a cursor will return those records or a search will find those records, depends on whether there's been a sync, that is, after the page is reconciled, the next scan/search will see the records, but while they're sitting on the append list, they'll not be seen by scans and will return not-found on a search.

      I figure that we can either document that fixed-length gets can return either not-found or 0x00 for implicitly created records, or, we can change things so the search functions and cursor functions figure out if there's a missing record and return empty data for it.

      I also wondered if this is a problem for existing table code that's splitting up columns among multiple files?

      I took a look at the code changes we'd need to make this all consistent, and they aren't too bad, with one exception: the changes to make __cursor_skip_prev() work for this case are daunting. (My plan was to check to see if the next entry on the skip list is recno - 1, or if there are missing records, maybe there's something better?)

      If we want to do the code changes, maybe we could do page searches for the specific record number instead of a previous-scan for bit-fields? Or am I misunderstanding how __cursor_skip_prev() works, and it's not so bad?



          Issue Links



              keith.bostic Keith Bostic
              wiredtiger WiredTiger
              0 Vote for this issue
              0 Start watching this issue