Affects Version/s: 3.2.4, 3.3.1
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.
- 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 from Repository:
Pull Master Branch:
Pull Master Diff URL:
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|
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.