Runaway controlled_vocabs table after 3.2.1.1 to 3.3.0.6 Upgrade

Hi

We are have a major problem after upgrading our system at from 3.2.1.1 to 3.3.0.6 on Weds. The upgrade script (run from web UI) reported a successful upgrade, but we have had a major performance slowdown.

After upgrading the system hardware on Thurs (to no avail), a bit more digging today (Fri) reveals that our controlled_vocabs table has grown from 265,112 rows (17.5MiB) to 2,731,268 rows (172.7MiB) and continues to grow at about 5000 rows per hour.

Since our test system did not experience this issue (either of performance or controlled_vocabs table bloat), I suspect that something ran differently when we upgraded the production server and corrupted the database.

Rolling back to Weds morning already can lose 3 days of work both for users and admins … any chance of a quick / easy solution to repair/rebuild this table would be a godsend!

Thanks for your help - happy to provide database copies…

~Steve

PS. I guess that this table is vital for a vanilla installation such as ours - we do not do anything specific with controlled vocab and could well disable / reset if it is an optional extra…

Hi all,

This was caused by a missing controlled_vocab_symbolic index on the controlled_vocabs table. It can be created with:

CREATE UNIQUE INDEX controlled_vocab_symbolic ON controlled_vocabs (symbolic, assoc_type, assoc_id);

…but the duplicate data in controlled_vocabs needs to be cleared out first.

Regards,
Alec Smecher
Public Knowledge Project Team

This topic was automatically closed after 6 days. New replies are no longer allowed.