Date: Thu, 3 Aug 2006 15:43:07 -0400 From: Richard Morse <remorse@partners.org> To: Richard Morse <remorse@partners.org> Cc: freebsd-questions@freebsd.org Subject: Re: Problems with MySQL since upgrade Message-ID: <607A6828-089C-4D21-B5F5-E88249F831D0@partners.org> In-Reply-To: <1E8F77CE-AC74-4C24-89DC-89201CD4E113@partners.org> References: <31F1465C-5B87-4B79-8D58-0A538BF30562@partners.org> <D1FBD2B5-CEB6-479B-8254-497E199462CF@partners.org> <80f4f2b20608020636o3dd712c9vf1aad9b6f3ba6e6f@mail.gmail.com> <B4660167-78AB-4A4D-AF7C-9AD258185E7C@partners.org> <80f4f2b20608020700l53410a09u6efb90aadb6294cb@mail.gmail.com> <1E8F77CE-AC74-4C24-89DC-89201CD4E113@partners.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! I finally figured out what was going on. Thanks for the people who gave suggestions. The query I thought was the problem really wasn't -- at some point between 5.0.13 and 5.0.22 a change was introduced which affected inner joins. I had a view which was aggresively created using inner joins (in order to take an EAV-like table and view it as though it were a regular table), and if I tried to do a three table inner join with a view involved, it sat there and entered some kind of loop. This either caused the tables to be locked, and later queries involving these tables were waiting for a freed lock, or eventually the number of open connections / threads climbed too high and all later connections were waiting. I was able to (for now) solve the problem by recreating the view as a realized table which gets rebuilt every hour. Thanks, Ricky
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?607A6828-089C-4D21-B5F5-E88249F831D0>