nettika/geary
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Don't multithread db upgrades

Browse source 
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
This commit is contained in:
Charles Lindsay 2014-03-03 17:40:53 -08:00
parent c4020014da
commit 85d1a97129
2 changed files with 15 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

6
sql/version-018.sql
View file

@ -1,6 +1,4 @@
--
-- Nuke the internaldate_time_t column, because it had the wrong values. It'll
-- be repopulated in code, in imap-db-database.vala.
-- Dummy upgrade to nuke the internaldate_time_t column, because it had the
-- wrong values. It'll be repopulated in code, in imap-db-database.vala.
--
UPDATE MessageTable SET internaldate_time_t = NULL;