Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-59506

DB lock factory cannot be used during install

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 3.2.4, 3.3.1
    • Fix Version/s: 3.2.5, 3.3.2
    • Component/s: Libraries
    • Labels:
    • Testing Instructions:
      Hide
      1. To be performed against postgres, and one other database
      2. Create a new site, with new, empty dataroot, but do not install
      3. Step through the installer, choosing an empty database, and enter the database details - click save
        1. Confirm that the styling is applied in the copyright and next installation pages.
      Show
      To be performed against postgres, and one other database Create a new site, with new, empty dataroot, but do not install Step through the installer, choosing an empty database, and enter the database details - click save Confirm that the styling is applied in the copyright and next installation pages.
    • Affected Branches:
      MOODLE_32_STABLE, MOODLE_33_STABLE
    • Fixed Branches:
      MOODLE_32_STABLE, MOODLE_33_STABLE
    • Pull Master Branch:
      MDL-59506-master

      Description

      As we use locks more, we may hit this again.
      The recent changes to styles.php mean that we attempt to get a lock during install.

      Unless a specific lock factory is set in config, the default is:

      • Try and fetch a lock factory for the current database
        • if it does not exist, then use the file lock factory;
        • if it does exist, but is not available, fall back to generic db_record locking.

      Consider the following scenarios:

      Database DB-Specific factory exists? Fallback factory
      Postgres Yes db_record
      Any other... No file

      Since postgres does have a DB-specific factory, if it is somehow not available (not possible with the way the code is called), the fallback would be a generic DB factory.

      To solve this issue the obvious thing to do is to use the file_lock_factory during initial install.
      However, I wonder whether we should be standardising the fallback so that if the DB-specific factory returns as being unavailable, we always use the same file_lock_factory, or whether we should switch all other Ds to use the db_record_lock_factory instead.

      Possibly this should be a different issue.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  11/Sep/17