• Charles Lindsay's avatar
    Don't multithread db upgrades · 85d1a971
    Charles Lindsay authored
    Turns out for long-running upgrades we were running them all in
    parallel, which thrashes the disk pretty hard.  This adds a simple mutex
    lock around each upgrade, so at least the computer is usable while it's
    going on.  A more robust solution would be to have a single-thread
    thread pool where we enqueue upgrades, but that's too much change this
    late in the release cycle.
    
    Also it turns out that the nullifying of the internaldate_time_t column
    before we repopulate it was very costly, and unnecessary.  So, this also
    should speed things up for upgrading users.
    
    Closes: bgo #724475
    85d1a971
Name
Last commit
Last update
..
CMakeLists.txt Loading commit data...
version-001.sql Loading commit data...
version-002.sql Loading commit data...
version-003.sql Loading commit data...
version-004.sql Loading commit data...
version-005.sql Loading commit data...
version-006.sql Loading commit data...
version-007.sql Loading commit data...
version-008.sql Loading commit data...
version-009.sql Loading commit data...
version-010.sql Loading commit data...
version-011.sql Loading commit data...
version-012.sql Loading commit data...
version-013.sql Loading commit data...
version-014.sql Loading commit data...
version-015.sql Loading commit data...
version-016.sql Loading commit data...
version-017.sql Loading commit data...
version-018.sql Loading commit data...
version-019.sql Loading commit data...