Possibly moving to InnoDB
mkanat at bugzilla.org
Sat Aug 5 15:18:08 UTC 2006
On Sat, 2006-08-05 at 22:29 +1000, Bradley Baetz wrote:
> > Okay. In many cases, that would actually be fine for us, as long as the
> > timeout is long enough. MySQL would just be automatically killing the
> > long-running queries that we kill by hand in places like bmo.
> It can be tweaked; I forget what the default is. But it doesn't kill
> the *running* query - it kills the blocking one. (All together now -
But wait, that makes sense. You mean if a SELECT is blocking everybody
else from running, it kills the SELECT, right?
> in a transaction. This takes up to 15-20 minutes to run, pulling a few
> hundred thousand rows each time.
Thankfully nothing in Bugzilla does that, except for collectstats.pl
> Fixed in 4.1.11 and 5.0.3, by introducing the SLAVE_TRANSACTION_RETRIES option
Okay. So we should recommend that if people are going to use
replication, they use at least 4.1.11 or 5.0.3.
> I think its meant to be, but may interact with manual LOCKs a bit
> oddly - since you can't LOCK TABLE more than once per transaction, I'm
> not sure if the 'implicit' lock works. It didn't used to work, but
> that was a few years ago, and I may be misremembering it.
I was reading something about it. There's something about table-level
locks and the implicit row-level locks caused by transactions.
> Oh, postgres has its own issues. They just fix them rather than
> calling them features....
Yeah. Sometimes, at least. :-)
Everything Solved: Competent, Friendly Bugzilla and Linux Services
More information about the developers