Tags: thg2k/mysql-server
Tags
Bug#35231475: Segmentation fault in Item_ref::real_item with
CTE query
When transforming a subquery to a derived table, if a new field is added,
it should increment the reference count. However, this was not done when
a view reference was replaced with a new field. This made the field
referenced to be deleted when it was wrongly concluded that the field is
unused. Problem arises because the same underlying field is referenced by
all the view references created for that field.
For a query like this one:
WITH cte AS (SELECT
(SELECT COUNT(f1) FROM t1),
COUNT(dt.f2),
dt.f3
FROM (SELECT * FROM t1) AS dt)
SELECT * FROM cte;
it gets transformed into
select `derived_2_6`.`COUNT(f1)` AS `(SELECT COUNT(f1) FROM t1)`,
`derived_2_5`.`COUNT(dt.f2)` AS `COUNT(dt.f2)`,
`derived_2_5`.`Name_exp_1` AS `f3`
from (select count(`test`.`t1`.`f2`) AS `COUNT(dt.f2)`,
`test`.`t1`.`f3` AS `Name_exp_1`
from `test`.`t1`) `derived_2_5`
left join (select count(`test`.`t1`.`f1`) AS `COUNT(f1)`
from `test`.`t1`) `derived_2_6` on(true) where true;
The expression "Name_exp_1" is a view reference because the derived
table "dt" gets merged. When this is replaced with an "Item_field"
during subquery to derived transformation, we do not increment the
reference count. Later, we see that the derived table "cte" which
is resolved after the creation of the derived tables "derived_2_5"
and "derived_2_6" gets merged. While deleting the un-used fields for
this derived table, we delete the field "f3" even though it is still
used in the query.
Fix is to correctly increment the ref count for the new field created.
Change-Id: I4035d86990e3cfb099144b7f304b864eb0451f5d
Bug#35231475: Segmentation fault in Item_ref::real_item with
CTE query
When transforming a subquery to a derived table, if a new field is added,
it should increment the reference count. However, this was not done when
a view reference was replaced with a new field. This made the field
referenced to be deleted when it was wrongly concluded that the field is
unused. Problem arises because the same underlying field is referenced by
all the view references created for that field.
For a query like this one:
WITH cte AS (SELECT
(SELECT COUNT(f1) FROM t1),
COUNT(dt.f2),
dt.f3
FROM (SELECT * FROM t1) AS dt)
SELECT * FROM cte;
it gets transformed into
select `derived_2_6`.`COUNT(f1)` AS `(SELECT COUNT(f1) FROM t1)`,
`derived_2_5`.`COUNT(dt.f2)` AS `COUNT(dt.f2)`,
`derived_2_5`.`Name_exp_1` AS `f3`
from (select count(`test`.`t1`.`f2`) AS `COUNT(dt.f2)`,
`test`.`t1`.`f3` AS `Name_exp_1`
from `test`.`t1`) `derived_2_5`
left join (select count(`test`.`t1`.`f1`) AS `COUNT(f1)`
from `test`.`t1`) `derived_2_6` on(true) where true;
The expression "Name_exp_1" is a view reference because the derived
table "dt" gets merged. When this is replaced with an "Item_field"
during subquery to derived transformation, we do not increment the
reference count. Later, we see that the derived table "cte" which
is resolved after the creation of the derived tables "derived_2_5"
and "derived_2_6" gets merged. While deleting the un-used fields for
this derived table, we delete the field "f3" even though it is still
used in the query.
Fix is to correctly increment the ref count for the new field created.
Change-Id: I4035d86990e3cfb099144b7f304b864eb0451f5d
Update License Book Approved-by: Erlend Dahl <[email protected]>
Update License Book Approved-by: Erlend Dahl <[email protected]>
Update License Book Approved-by: Balasubramanian Kandasamy <[email protected]> (cherry picked from commit eee3f0851c4942a11b2e55818d51484de016fcd4)
Update License Book Approved-by: Erlend Dahl <[email protected]> (cherry picked from commit 3b764381c3711246e137f74756318711bcb8c431)
Update License Book Approved-by: Erlend Dahl <[email protected]> (cherry picked from commit 6e3f106eaace16f20f9268f0c67203ac5c5e98a5)
Bug #34857411 : regression - slow connections/telnet block many other… … statements for connect_timeout seconds, causing pileups [post-push-fix] Fixing the sporadically failing testcase on PB2 Approved by Harin Vadodaria <[email protected]> over Slack.
Bug #34857411 : regression - slow connections/telnet block many other… … statements for connect_timeout seconds, causing pileups [post-push-fix] Fixing the sporadically failing testcase on PB2 Approved by Harin Vadodaria <[email protected]> over Slack.
PreviousNext