>>>>> "elble" == elble <elble@stripped> writes:
>> > but, am i the only person who has this problem?
elble> i was actually refering to the set sql_low_priority_updates=1 command
elble> failing here...
>> In general read and write locking is not intuitive. Whether at the
>> system or application level it usually takes time and effort to
>> understand get used to the 'logic'.
elble> but, you're 100% correct here.
elble> i should have seen that an acquired read lock was similar to a very long
elble> select statement.
elble> my folly has revealed itself!
elble> now, if i could just get rid of the rest of my follies, i could
elble> be bored. ;-)
Some comments to this thread:
Why not use:
mysqldump --flush-logs --lock-tables
(If I understand correctly, this will do exactly what you wanted)
didn't work in 3.22.25 (will be fixed in 3.22.26)
You can instead start mysqld with:
[INSERT | UPDATE | DELETE] LOW_PRIORITY ...
The problem with locks are the following:
If you do (in this time order)
#1 LOCK TABLES test READ
#2 LOCK TABLES test WRITE
#3 LOCK TABLES test READ
#1 has a read lock on the table.
#2 has a 'wait for write lock' on the table
#3 has a 'wait for read lock' on the table.
#3 has to wait for #2 as write locks has (normally) higher privilege
than read locks.
The reason for this is if you would allow SELECT's to proceed on
tables where there is a 'waiting write lock', then if you issue new
selects the whole time, it's likely that there will never be a time when
the table is 'free' and the clients that wants to update will starve
In the case of INSERT's, you can probably avoid this by using 'INSERT DELAYED