**Comment from Launchpad by: Fernando Ipar on: 08-03-2013 21:39:14

Daniel:

I don't think it's the same error. bug 1046483 is about a connection being killed, while this one is about mysql and mysqladmin failing due to 'too many connections' errors that may happen if Threads_connected is too close (or over) max_connections.

I've linked a POC branch I've just made where collect checks the Threads_connected and max_connections, and if there are less than 10 available connections, does not send captures to the background. It worked on my manual simple tests (Just pt-stalk --no-stalk --iterations 1 , with enough connections, and with just 1 available), but again, it's just a POC

**Comment from Launchpad by: Daniel Nichter on: 01-10-2012 20:00:46

This general bug is appearing more and more, and being mentioned by more people, what I would call "connection resiliency". For example: bug 1046483. It is, however, a big engineering task because the major tools can have lots of connections, some of which are "primary", others "auxiliary". And each possible point of failure needs to be carefully considered: is the original operation idempotent? I.e. can we re-connect, re-execute, and carry on? And are half failures/successes possible? Etc. etc. The general motivation is good though: don't let connection "hiccups" kill the whole tool, especially long-running tools.