Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-662

during crash recovery of a drop table, on case insensitive files systems derby may delete wrong file

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 10.0.2.0, 10.1.2.1
    • Fix Version/s: 10.0.2.2, 10.1.2.1, 10.2.1.6
    • Component/s: Store
    • Labels:
      None
    • Environment:
      jvm/os/filesystem where file names are case insensitive such that delete of C2080.dat will remove c2080.dat if it exists.

      Description

      Sometimes during redo the system will incorrectly remove the file associated
      with a table. The bug requires the following conditions to reproduce:
      1) The OS/filesystem must be case insensitive such that a request to delete
      a file named C2080.dat would also remove c2080.dat. This is true in
      windows default file systems, not true in unix/linux filesystems that
      I am aware of.
      2) The system must be shutdown not in a clean manner, such that a subsequent
      access of the database causes a REDO recovery action of a drop table
      statement. This means that a drop table statement must have happened
      since the last checkpoint in the log file. Examples of things that cause
      checkpoints are:
      o clean shutdown from ij using the "exit" command
      o clean shutdown of database using the "shutdown=true" url
      o calling the checkpoint system procedure
      o generating enough log activity to cause a regularly scheduled checkpoint.
      3) If the conglomerate number of the above described drop table is TABLE_1,
      then for a problem to occur there must also exist in the database a table
      such that it's HEX(TABLE_2) = TABLE_1
      4) Either TABLE_2 must not be accessed during REDO prior to the REDO operation
      of the drop of TABLE_1 or there must be enough other table references during
      the REDO phase to push the caching of of the open of TABLE_2 out of cache.

      If all of the above conditions are met then during REDO the system will
      incorrectly delete TABLE_2 while trying to redo the drop of TABLE_1.
      <p>
      I will be adding the following test to reproduce the problem:
      1) create 500 tables, need enough tables to insure that conglomerate number
      2080 (c820.dat) and 8320 (c2080.dat) exist.
      2) checkpoint the database so that create does not happen during REDO
      3) drop table with conglomerate number 2080, mapping to c820.dat. It looks
      it up in the catalog in case conglomerate number assignment changes for
      some reason.
      4) exit the database without a clean shudown, this is the default for test
      suites which run multiple tests in a single db - no clean shutdown is done.
      Since we only do a single drop since the last checkpoint, test will cause
      the drop during the subsequent REDO.
      5) run next test program dropcrash2, which will cause redo of the drop. At
      this point the bug will cause file c2080.dat to be incorrectly deleted and
      thus accesses to conglomerate 8320 will throw container does not exist
      errors.
      6) check the consistency of the database which will find the container does
      not exist error.

        Attachments

        1. dropcrash.diff
          14 kB
          Mike Matrigali

          Activity

            People

            • Assignee:
              mikem Mike Matrigali
              Reporter:
              mikem Mike Matrigali
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: