>>>>> "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. ;-)
Hi!
Some comments to this thread:
Why not use:
mysqldump --flush-logs --lock-tables
(If I understand correctly, this will do exactly what you wanted)
set SQL_LOW_PRIORITY_UPDATES=1;
didn't work in 3.22.25 (will be fixed in 3.22.26)
You can instead start mysqld with:
--low-priority-updates
or use:
[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
to death.
In the case of INSERT's, you can probably avoid this by using 'INSERT DELAYED
...'
Regards,
Monty
