Comments for domas mituzas: vaporware, inc.

Comment on Opening tables v2! by Antony Curtis

Antony Curtis — Fri, 26 Feb 2010 17:15:26 +0000

There is an old patch (you can search for it on the bk commits list) which safely releases the LOCK_open mutex before calling the storage engines ::open method. The patch was primarily for fixing DOS scenerio when using the Federated storage engine but it would be equally applicable in this case.

Comment on Opening tables v2! by Mark Callaghan

Mark Callaghan — Fri, 26 Feb 2010 15:52:35 +0000

I opened a bug — http://bugs.mysql.com/bug.php?id=51557

PMP is the best — http://mituzas.lt/2009/02/15/poor-mans-contention-profiling/

Comment on Opening tables! by Opening tables v2! « domas mituzas: vaporware, inc.

Opening tables v2! « domas mituzas: vaporware, inc. — Fri, 26 Feb 2010 15:04:53 +0000

[...] been seeing ‘Opening tables’ during proper operations, not just during startup (see my previous post on this [...]

Comment on Read ahead… by Domas Mituzas

Domas Mituzas — Thu, 18 Feb 2010 16:29:56 +0000

coolcold: ??

Comment on Read ahead… by CoolCold

CoolCold — Sun, 14 Feb 2010 14:01:06 +0000

Domas Mituzas discovered that mysqld does not properly handle errors during execution of certain SELECT statements..

\m/

Comment on Read ahead… by Domas Mituzas

Domas Mituzas — Sun, 17 Jan 2010 20:58:54 +0000

lv, ačiū ;)

Comment on Read ahead… by lv

lv — Sun, 17 Jan 2010 19:14:14 +0000

“… at two functions – buf_read_ahead_linear() and buf_read_ahead_random() …”

Comment on Opening tables! by Bill Karwin

Bill Karwin — Thu, 31 Dec 2009 19:39:46 +0000

Well done! That’s a great analysis and a great fix.

Comment on PMP! by Darius Jahandarie

Darius Jahandarie — Thu, 31 Dec 2009 02:12:38 +0000

Poor man’s repository!

Excellent work though hehe.

Comment on When bad things happen! by Domas Mituzas

Domas Mituzas — Tue, 29 Dec 2009 21:55:54 +0000

Mark, there’s no easy syscall/ptrace module either in perl nor python nor php. ‘make a’ works though :-)

Comment on When bad things happen! by Mark Callaghan

Mark Callaghan — Tue, 29 Dec 2009 19:36:23 +0000

A Perl/Python version of this would be easier to use.

Comment on When bad things happen! by Eric Bergen

Eric Bergen — Tue, 29 Dec 2009 17:23:10 +0000

There was an issue on rhel4 where if a tracing process didn’t call ptrace detach that the thread group leader would stay in traced state. If someone sent it a SIGCONT the thread group leader would continue and all the child threads would go into a traced state (T in ps). A second SIGCONT would bring it back to normal. Between the two signals a ps ax would show only the thread group leader status. Be sure to check the threads in ps to make sure none of them are in a traced state.

Comment on PMP! by Aistis

Aistis — Mon, 28 Dec 2009 16:46:26 +0000

awesome %)

Comment on PMP! by Domas Mituzas

Domas Mituzas — Mon, 28 Dec 2009 10:30:56 +0000

Why project page? This isn’t project, this is technology! :-)

Comment on PMP! by Mark Callaghan

Mark Callaghan — Sun, 27 Dec 2009 20:40:29 +0000

Where is the project page? launchpad? google? kenai?

Comment on Opening tables! by Matt Montgomery

Matt Montgomery — Sat, 26 Dec 2009 16:28:33 +0000

This is Bug #49463 (http://bugs.mysql.com/bug.php?id=49463)
I’ve linked your patch to this report.

Comment on On deadlock detection by Domas Mituzas

Domas Mituzas — Tue, 22 Dec 2009 13:12:34 +0000

Arjen, indeed – we already have such a switch ;-) On systems that hit deadlocks every hour or so it is very feasible to wait a bit longer :)

Comment on On deadlock detection by Arjen Lentz

Arjen Lentz — Tue, 22 Dec 2009 00:18:49 +0000

So would it be viable to have a switch for deadlock detection, and being able to turn it off…. of course you’d want the innodb_lock_timeout to be very short (the 50 secs default is ridiculously high anyway).

Comment on A formal objection to formal objection! by Mike.lifeguard

Mike.lifeguard — Thu, 17 Dec 2009 00:35:00 +0000

4.0.forever :D

Comment on On replication, some more by Wikipédia : actus diverses « Darkoneko's Weblog

Wikipédia : actus diverses « Darkoneko's Weblog — Tue, 15 Dec 2009 07:47:15 +0000

[...] Mituzas se lamente sur certains manques de MySQL 5.1. Mon petit doigt me dit que ça n’est pas étranger au [...]

Comment on On replication, some more by Domas Mituzas

Domas Mituzas — Mon, 14 Dec 2009 18:51:43 +0000

In MySQL lingo, simply toggle log-slave-updates – and yeah, if there’re multiple masters, do that per-master :)

Comment on best free() is exit() by Rich Farmbrough

Rich Farmbrough — Mon, 14 Dec 2009 17:16:52 +0000

Yes I had a similar but worse problem with a SQL database, it was taking too long to perform a query then when told to stop tried to roll-back the query. Even re-starting the database mean it tried to do hours of cleanup before letting a humble user in to drop the tables. The quickest solution was to delete and rebuild the (effectively) empty database. And it was trying to be user friendly.

Comment on On replication, some more by Jay Pipes

Jay Pipes — Mon, 14 Dec 2009 14:35:08 +0000

Hi Domas,

So, regarding Drizzle, some things in your list above are done, some aren’t. Heck, Drizzle replication is really new, so don’t expect much in terms of features at this point…I’m focusing on fixing bugs and stability over features right now. The nice thing is that the API is very simple and pluggable, and different modules can allow a pretty fine-tuned customization of the replication system.

That said, I don’t *quite* understand what you are really requesting with this:

“Allow to enable and disable binary logging of events received from master, as well as enabling and disabling binary logging without restarting the instance.”

Which of these are yourequesting?

* to enable/disable ALL logging of events on the SLAVE that have been received from ANY master
* to enable/disabled logging of SPECIFIC events on the SLAVE that have been received from ANY master
* to enable/disable the APPLY (not the logging) of specific events on the SLAVE from ANY master
* something else? :)

Thanks :)

Jay

Comment on On replication, some more by Domas Mituzas

Domas Mituzas — Mon, 14 Dec 2009 09:48:43 +0000

Does Drizzle do that nowadays with current replicator implementations?

Comment on On replication, some more by Stewart Smith

Stewart Smith — Mon, 14 Dec 2009 09:47:18 +0000

Let me tell you about Drizzle…..

Comment on On replication, some more by Robert Hodges

Robert Hodges — Mon, 14 Dec 2009 06:19:06 +0000

Hi Domas,

We have 3 out of 4 of these requirements covered with Tungsten (http://www.continuent.com/community). I’m about to start a series of blog articles on the solution to the second problem, which we plan to deploy early in 2010. Would you mind expanding the specific cases–is it a matter of replication being single threaded, the fact there’s a single client tcp/ip connection from slave to master, etc.?

Meanwhile, please have a look at Tungsten.

Cheers, Robert

Comment on best free() is exit() by Jay Pipes

Jay Pipes — Fri, 11 Dec 2009 14:34:13 +0000

In some cases I agree with you, Domas. Memory allocated in static space (like some of the InnoDB data dictionary, nss lookup stuff, pcre state, etc, can be a little over-the-top to manually free at shutdown.

However, there are certain circumstances where the *order* of de-allocation makes a difference. For instance, in Drizzle, shutting down global heap-allocated stuff before calling each plugin’s destructor would be, well, not a good idea :) So, I partly agree and partly disagree. :) When in doubt, I always prefer explicit over implicit.

Cheers!
Jay

Comment on best free() is exit() by walrus

walrus — Fri, 11 Dec 2009 08:46:39 +0000

yes, flushing the whole heap is much cheaper than every variable one by one.

That is strong side of erlang (for instance), where each thread has it’s own heap. when the thread ends, erlang flushes the the whole heap of that thread.

Comment on best free() is exit() by Davi Arnaut

Davi Arnaut — Thu, 10 Dec 2009 17:25:05 +0000

I think you are aiming at the wrong direction. If developers structured things in a proper way (eg, memory root), traversing should be minimal. Also, the kernel has to do this too, freeing memory is not that simple and can cause severe latency. Nonetheless, this is not about perfection, its about consistency (and special cases for tools are not welcome). There is also a reason why this must be done in mysql in some cases: embedded.

Comment on best free() is exit() by Vladislav Vaintroub

Vladislav Vaintroub — Thu, 10 Dec 2009 16:46:53 +0000

I agree that complicated cleanup is a bad idea. And that people write this code to just please tools that find false positives also does not sound good.