85d1a97129
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 |
||
|---|---|---|
| .. | ||
| CMakeLists.txt | ||
| version-001.sql | ||
| version-002.sql | ||
| version-003.sql | ||
| version-004.sql | ||
| version-005.sql | ||
| version-006.sql | ||
| version-007.sql | ||
| version-008.sql | ||
| version-009.sql | ||
| version-010.sql | ||
| version-011.sql | ||
| version-012.sql | ||
| version-013.sql | ||
| version-014.sql | ||
| version-015.sql | ||
| version-016.sql | ||
| version-017.sql | ||
| version-018.sql | ||
| version-019.sql | ||