[MDEV-33081] Crash on second execution of PS for query over many views Created: 2023-12-20 Updated: 2024-01-23 |
|
| Status: | Stalled |
| Project: | MariaDB Server |
| Component/s: | Optimizer |
| Affects Version/s: | 10.4, 10.5, 10.6, 10.11, 11.0, 11.1, 11.2, 11.3 |
| Fix Version/s: | 10.4 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Igor Babaev | Assignee: | Igor Babaev |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
The following test case causes a crash of the server on the second execution of used PS:
The crash happens in Dep_analysis_context::get_field_value() with
With the setting
both execution of the used PS return the expected result set. |
| Comments |
| Comment by Oleg Smirnov [ 2024-01-10 ] | ||||||||||||||||||||||||||||||||||||||
|
The problem seems to be related to the unsuccessful merging of view v2. After the parsing stage dbug_print(select_lex) prints the following statement:
At 1st execution mysql_derived_prepare() sets flag "mergeable" for v2 and creates the field translation table. After names resolution select_lex looks like
Note the t9.b in the select lists. It's the reference that was translated from v2.b as the view v2 is expected to be merged. At the optimization stage we hit the following limitation:
Then the next code block works which rolls back the preparation for merging and sets the view v2 to "materialized":
After derived->change_refs_to_fields() select_lex looks as follows (only first 300 characters shown):
There is again v2.b in the select lists, which is correct. But the merging of derived tables and views is performed only during the first execution:
So at the 2nd execution we lack the call of derived->change_refs_to_fields() and end up have incorrect references to t9.b in the select lists:
As a result, there are incorrect table_maps and a crash at table elimination (which is not related to the elimination itself, however) | ||||||||||||||||||||||||||||||||||||||
| Comment by Oleg Smirnov [ 2024-01-13 ] | ||||||||||||||||||||||||||||||||||||||
|
igor, can you please review the proposed solution in branch bb-10.4-mdev-33081?
| ||||||||||||||||||||||||||||||||||||||
| Comment by Igor Babaev [ 2024-01-14 ] | ||||||||||||||||||||||||||||||||||||||
|
An explanation of the proper second execution of the reported PS with | ||||||||||||||||||||||||||||||||||||||
| Comment by Oleg Smirnov [ 2024-01-15 ] | ||||||||||||||||||||||||||||||||||||||
|
The code outside the table elimination turns out to be tolerant to such inconsistency, at least for the given test case. But I've managed to reproduce the error with the table elimination turned off. Look at the modification of your original test case :
The correct result is NULL, but the non-patched 10.4 outputs 202 at the second execution of the PS. At the same time, the patched version produces NULL at both executions. | ||||||||||||||||||||||||||||||||||||||
| Comment by Oleg Smirnov [ 2024-01-16 ] | ||||||||||||||||||||||||||||||||||||||
|
One more note: no tables are eliminated in the test cases above. This can be checked be setting breakpoints at
and
Those breakpoint are never hit. | ||||||||||||||||||||||||||||||||||||||
| Comment by Igor Babaev [ 2024-01-18 ] | ||||||||||||||||||||||||||||||||||||||
|
This bug will be fixed when a fix for MDEV-30073 is pushed into 10.4 |