> [tara CC'd for education/documentation purposes.] > > brade told me this morning that Bugzilla was very slow. I eventually > discovered that the "queryagainstshadowdb" param was turned off. This > means that although all the work was being done to maintain the shadow > database, nothing was actually using it for anything. > > I turned the parameter on. I then found the mysql threads that seemed > to be wedging things, and killed them. (I invented a new trick: > "mysqladmin proc | grep -v Locked" gives a list of mysql threads that > are not just hanging on other threads.) And everything dewedged and > started behaving again. > > The other mystery is "how did the queryagainstshadowdb param get turned > off"? I think this can happen if the nightly "syncshadowdb -syncall" > job dies or gets killed. This should somehow be noticed, and a mail sent to the admin that cleanup will probably be necessary.

-> Bugzilla product, Administration component, reassigning.

We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.

syncshadowdb is gone (as is queryagainstshadowdb), so this is no longer an issue. Besides, I don't thnk this has been seen since this bug was filed 2.5 years ago. INVALID

clearing target on INVALID/WORKSFORME/WONTFIX/DUPLICATE so they'll show up as untriaged if they get reopened.