At 17:53 +1100 12/11/02, Stephen Brownlow wrote:
Hello Paul,

I am only lobbying, not demanding.
Sorry.  I wasn't trying to imply that you were demanding.
It's just that experience shows that feature implementation
always seems easy to the people who aren't doing the work. :-)

Paul Dubois wrote:

 Mmm, how do you know how much effort it would be?
 Have you implemented it?
Ok. IMHO it would be relatively easy for MySQL to implement, judging by my
experience dealing with Monty and his source code (specifically, the myisam
API).

I await comments from MySQL AB.

 Write a client that flushes all the tables, then places a write lock
 on them all.  That will keep anyone else from modifying them.
Will it stop mysqld from reading them?
Yes. When the client places the write lock, it's the server that grants
the lock request, so it knows that only the client that holds the lock
can make changes.  In the situation at hand, that client won't make any
changes; it's grabbing the lock only to prevent *other* clients from
making changes.

Some maintenance processes such as myisamchk will actually move the files
around, which could confuse mysqld.
That's why the client acquires a write lock and then doesn't make any
changes itself.

This is described in more detail in chapter 13 of that New Riders book.


 Run myisamchk.  When it's done, flush the tables again and unlock them.
While that might be workable, don't you think the proposal would be both
safer and simpler?
Sure.  But in the absence of that capability, the procedure described
might be useful in some way.

Thanks,
Stephen

---------------------------------------------------------------------
Before posting, please check:
  http://www.mysql.com/manual.php   (the manual)
  http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to