-
Jan Lindström authored
Thread executing wsrep transaction can't change during transaction execution. Similarly, thread executing high priority brute force (BF) transaction does not change during transaction execution. Therefore, in both cases there is no need to call server code after transaction has initialized. InnoDB already stores information is this wsrep transaction to trx_t::wsrep and this is checked using trx->is_wsrep() function. Because, brute force transaction is always a wsrep transaction we can extend trx_t::wsrep variable so that value 0 == not wsrep transaction (and not BF) 1 == normal wsrep transaction 2 == high priority BF wsrep transaction 4 == high priority BF transaction is performing unique secondary index scan These values can be set by calling server code on innobase_trx_init(). After that we can use trx_t::is_wsrep() and new function introduced in this patch trx_t::is_wsrep_BF(). Unique secondary index scan is determined later but it implies BF, so this patch removes unnecessary variable trx_t::wsrep_UK_scan. Patch introduces new functions trx_t::is_wsrep_UK_scan(), wsrep_begin_UK_scan() and wsrep_end_UK_scan() to handle unique secondary index scan. This change reduces number of calls to server code from InnoDB and reduces code bloat on performance critical stages like acquiring record locks. Furthermore, it simplifies code on several locations. This patch also removes unnecessary trx_t::wsrep_event that was always set to NULL and not used. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
dc4e5281