My delayed reply:
root 24066 21302 31 11:30 pts/1 00:00:00 /usr/bin/perl -T -w /usr/bin/sa-learn --sync --dbpath /var/qmail/mailnames/DOMAIN/USER/.spamassassin
root 21302 21282 0 11:18 pts/1 00:00:05 /bin/sh /var/tmp/rpm-tmp.Ja9Hko 2
root 21282 4684 0 11:18 pts/1 00:00:00 /bin/sh /var/tmp/rpm-tmp.Ja9Hko 2
root 4684 16967 2 11:13 pts/1 00:00:23 /usr/bin/python /usr/local/psa/bin/yum_install -e PPB_11_0_9-dist -e PPB_11_0_9-thirdparty -e PSA_11_0_9-dist -e PSA_11_0_9-thirdparty -e SITEBUILDER_11_0_10-dist -e SITEBUILDER_11_0_10-thirdparty -p -l /tmp/autoinstaller3.log -i plesk-base -i plesk-core -i plesk-l10n -i plesk-mail-qc-driver -i plesk-skins -i pp-sitebuilder -i pp-sitebuilder-default-templates -i pp-sitebuilder-skins -i pp11.0.9-bootstrapper -i psa -i psa-autoinstaller -i psa-awstats-configurator -i psa-backup-manager -i psa-ftputil -i psa-horde -i psa-imp -i psa-ingo -i psa-kronolith -i psa-libpam-plesk -i psa-locale-base-en-US -i psa-mail-driver-common -i psa-migration-agents -i psa-migration-manager -i psa-mimp -i psa-mnemo -i psa-mod_aclr2 -i psa-mod_fcgid -i psa-mod_rpaf -i psa-php5-configurator -i psa-proftpd -i psa-pylibplesk -i psa-selinux -i psa-spamassassin -i psa-triggers -i psa-turba -i psa-updates -i psa-vhost -i psa-watchdog -i psa11-php-fakepackage
root 16967 26447 1 11:05 pts/1 00:00:17 /var/cache/parallels_installer/parallels_installer_CentOS_6_x86_64
So yes, something in the upgrade process causes sa-learn to run against every single mailbox on the server, while leaving the upgrade incomplete and web server down. So upgrades from 10 to 11, instead of completing with a few minutes of downtime and running the learn process later, can run into the 30+ minute range on servers with a large number of email accounts. For example, in the above, I'm now at the 25 minute mark.