On Wed, Sep 15, 2010 at 2:00 PM, Sergei Golubchik <serg@askmonty.org> wrote:

Hi, Weldon!

Hi, Sergei!

On Sep 15, Weldon Whipple wrote:

<snip/>

...

2. FLUSH TABLES WITH READ LOCK FOR DATABASE dbname;

(I just added an optional 'FOR DATABASE dbname' to the already existing command--which still works, BTW. Is this a misuse of the word "FOR"?) This is the command that locks the tables before someone (some program) dumps/copies the tables that will be moved to another server. It flushes and locks only one database.

This would be difficult to implement.

FLUSH TABLES WITH READ LOCK is not implemented in a way that can be generalized to support per-database locks :(

I had guessed as much. (The method in my DB_BINLOG_MGR method that implements that functionality consists of a mutex lock, a comment about some sort of miracle happening, then a mutex unlock.) I wonder if there might be a way of inhibiting some user database (temporarily) from changing ... Alternately, I suppose we could do a global FLUSH TABLE WITH READ LOCK/ UNLOCK TABLES. Or ... (???)

Besides, I personally wouldn't worry much about the syntax. It's something you can easily change anytime - e.g. replace BINLOG with BINLOGGING or FOR with something else.

Yeah, every time I write a new prototype I tweak the syntax a bit. At the moment I'm just trying to settle on an implementation that would work for our company (and still be of some sort of general use).

Regards, Sergei

Thanks, Weldon