mirror of
https://github.com/MariaDB/server.git
synced 2025-01-29 02:05:57 +01:00
51519388f1
LOCAL TABLE WHEN ONLY 1 LOCAL ROW Description: When updating a federated table with UPDATE... JOIN, the server consistently crashes with Signal 11 when only 1 row exists in the local table involved in the join and that 1 row can be joined with a row in the federated table. Analysis: Interaction between the federated engine and the optimizer results in the crash. In our scenario, ie, local table having only one row, the program is following a different path because the table is treated as a constant table by the join optimizer. So in this scenario "index_read()" is happening in the prepare phase, since optimizer plan is different for constant table joins. In this case, "index_read_idx_map()" (inside handler.cc) is calling "index_read()" and inside "index_read()", matching rows are fetched and "stored_result" gets populated by calling "store_result()". And just after "index_read()", "index_end()" function is called. And in the "index_end()", its freeing the "stored_result" by calling "free_result()". So when it reaches the execution phase, in "position()" function, we are getting assertion at "DBUG_ASSERT(stored_result);". In all other scenarios (ie, table with more than 1 row), optimizer plan is different and "index_read()" is happening in the execution phase. Fix: So my fix is to have a separate ha_federated member function for "index_read_idx_map()" which will handle federated engine separately. So that position() will be called before index_end() call in constant table scenario. |
||
|---|---|---|
| .. | ||
| CMakeLists.txt | ||
| ha_federated.cc | ||
| ha_federated.h | ||