You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug#36186180 Updating histograms on offloaded tables can deadlock
When running ANALYZE TABLE UPDATE HISTOGRAM on a table that has been
loaded into the secondary engine the UPDATE HISTOGRAM command updates
both the primary and secondary table share with a snapshot of the
histograms. If, while histograms are being updated, another thread runs
a query that is offloaded to the secondary engine and this triggers the
creation of the secondary table share, then we can end up with a
deadlock where: 1) the histogram update thread is waiting on the
secondary share to be constructed before it can release histogram MDL,
and 2) the offloaded query is waiting for histogram MDL to be relased
before it can finish constructing the secondary share because part of
the work involved in constructing the table share involves retrieving
the histograms on the table from the dictionary.
This problem does not happen for tables that exist only in the primary
engine since we lock and open such tables before acquiring MDL on the
histograms. However, for tables that also exist in the secondary engine
we attempt to retrieve the secondary share at the point where we update
the primary share, so after having acquired MDL on the histograms, and
this creates the possibility of a deadlock.
This patch removes histograms from the secondary engine table share
altogether, thus avoiding the need the need to update both the primary
and secondary share when updating histograms. When optimizing an
offloaded query we are still able to use the histograms on the primary
table share. This saves memory by avoiding keeping additional copies of
the histograms on the secondary table share and avoids the type of lock
order violation causing the bug.
Change-Id: I36c22d217837a5c6e3e21151c9d1b353cdd86f77
0 commit comments