database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-08-08 11:22:35 +03:00
Code Activity

Bug#40536: SELECT is blocked by INSERT DELAYED waiting on

Browse Source 
upgrading lock, even with low_priority_updates

The problem is that there is no mechanism to control whether a
delayed insert takes a high or low priority lock on a table.

The solution is to modify the delayed insert thread ("handler")
to take into account the global value of low_priority_updates
when taking table locks. The value of low_priority_updates is
retrieved when the insert delayed thread is created and will
remain the same for the duration of the thread.
This commit is contained in:
Davi Arnaut
2009-02-03 15:16:24 -02:00
parent 6fb2ba1c3d
commit bc03c9ef19
5 changed files with 81 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
sql/sql_insert.cc
View File

@@ -1690,6 +1690,7 @@ public:
class Delayed_insert :public ilink {
uint locks_in_memory;
thr_lock_type delayed_lock;
public:
THD thd;
TABLE *table;
@@ -1731,6 +1732,8 @@ public:
pthread_cond_init(&cond_client,NULL);
VOID(pthread_mutex_lock(&LOCK_thread_count));
delayed_insert_threads++;
delayed_lock= global_system_variables.low_priority_updates ?
TL_WRITE_LOW_PRIORITY : TL_WRITE;
VOID(pthread_mutex_unlock(&LOCK_thread_count));
}
~Delayed_insert()
@@ -2540,7 +2543,7 @@ bool Delayed_insert::handle_inserts(void)
table->use_all_columns();
thd_proc_info(&thd, "upgrading lock");
if (thr_upgrade_write_delay_lock(*thd.lock->locks))
if (thr_upgrade_write_delay_lock(*thd.lock->locks, delayed_lock))
{
/*
This can happen if thread is killed either by a shutdown