• Jan Lindström's avatar
    MDEV-12837: WSREP: BF lock wait long · da3a3a68
    Jan Lindström authored
    Problem was a merge error from MySQL wsrep i.e. Galera.
    
    wsrep_on_check
    	New check function. Galera can't be enabled
    	if innodb-lock-schedule-algorithm=VATS.
    
    innobase_kill_query
    	In Galera async kill we could own lock mutex.
    
    innobase_init
    	If Variance-Aware-Transaction-Sheduling Algorithm (VATS) is
    	used on Galera we fall back to First-Come-First-Served (FCFS)
    	with notice to user.
    
    Changed innodb-lock-schedule-algorithm as read-only parameter
    as it was designed to be.
    
    lock_reset_lock_and_trx_wait
    	Use ib::hex() to print out transaction ID.
    
    lock_rec_other_has_expl_req,
    lock_rec_other_has_conflicting,
    RecLock::add_to_waitq
    lock_rec_lock_slow
    lock_table_other_has_incompatible
    lock_rec_insert_check_and_lock
    lock_prdt_other_has_conflicting
    
    	Change pointer to conflicting lock to normal pointer as this
    	pointer contents could be changed later.
    
    RecLock::create
    	Conclicting lock pointer is moved to last parameter with
    	default value NULL. This conflicting transaction could
    	be selected as victim in Galera if requesting transaction
    	is BF (brute force) transaction. In this case contents
    	of conflicting lock pointer will be changed. Use ib::hex() to print
    	transaction ids.
    da3a3a68
lock0lock.cc 228 KB