Possibly moving to InnoDB

[Max Kanat-Alexander]

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 -
> eww!)

	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
--regenerate.

>   Fixed in 4.1.11 and 5.0.3, by introducing the SLAVE_TRANSACTION_RETRIES option
> [snip]

	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. :-)

	-Max
-- 
http://www.everythingsolved.com/
Everything Solved: Competent, Friendly Bugzilla and Linux Services