database/mariadb-columnstore-engine
1
0
Fork 0
mirror of https://github.com/mariadb-corporation/mariadb-columnstore-engine.git synced 2025-07-29 08:21:15 +03:00
Code Activity

MCOL-5429 Fix high memory consumption in GROUP_CONCAT() processing.

Browse Source 
1. Input and output RowGroup's used in GROUP_CONCAT classes
are currently allocating a raw memory buffer of size equal
to the actual width of the string datatype. As an example,
for the following query:
  SELECT col1, GROUP_CONCAT(col2) FROM t GROUP BY col1;
If col2 is a TEXT field with default width, the input
RowGroup containing the target rows to be concatenated will
assign 64kb of memory for every input row in the RowGroup.
This is wasteful as actual field values in real workloads
would be much smaller. We fix this by enabling the
RowGroup to use the StringStore when the RowGroup contains
long strings.

2. RowAggregation::initialize() allocates a memory buffer
for a NULL row. The size of this buffer is equal to the
row size for the output RowGroup. For the above scenario,
using the default group_concat_max_len (which is a server
variable that sets the maximum length of the GROUP_CONCAT string)
value of 1mb, the buffer size would be
(1mb + 64kb + some additional metadata). If the user sets
group_concat_max_len to a higher value, say 3gb, this buffer
size would be ~3gb. Now if the runtime initiates several
instances of RowAggregation, total memory consumption by
PrimProc could exceed the hardware memory limits causing the
OS OOM to kill the process. We fix this problem by again
enabling the StringStore for the NULL row allocation.

3. In the plugin code in buildAggregateColumn(), there is
an integer overflow when the server group_concat_max_len
variable (which is an uint32_t) is set to a value > INT32_MAX
(such as 3gb) and is assigned to
CalpontSystemCatalog::ColType::colWidth (which is an int32_t).
As a short term fix, we saturate the assigned value to colWidth
to INT32_MAX. Proper fix would be to upgrade
CalpontSystemCatalog::ColType::colWidth to an uint32_t.
This commit is contained in:
Gagan Goel
2023-04-19 21:11:06 +00:00
parent 4fe9cd64a3
commit 0be1c3dc8f
6 changed files with 78 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
dbcon/mysql/ha_mcs_execplan.cpp
View File

@ -5348,7 +5348,24 @@ ReturnedColumn* buildAggregateColumn(Item* item, gp_walk_info& gwi)
// Item_func_group_concat* gc = (Item_func_group_concat*)isp;
CalpontSystemCatalog::ColType ct;
ct.colDataType = CalpontSystemCatalog::VARCHAR;
ct.colWidth = isp->max_length;
// MCOL-5429 CalpontSystemCatalog::ColType::colWidth is currently
// stored as an int32_t (see calpontsystemcatalog.h). However,
// Item_sum::max_length is an uint32_t. This means there will be an
// integer overflow when Item_sum::max_length > colWidth. This ultimately
// causes an array index out of bound in GroupConcator::swapStreamWithStringAndReturnBuf()
// in groupconcat.cpp when ExeMgr processes groupconcat. As a temporary
// fix, we cap off the max groupconcat length to std::numeric_limits<int32_t>::max().
// The proper fix would be to change colWidth type to uint32_t.
if (isp->max_length <= std::numeric_limits<int32_t>::max())
{
ct.colWidth = isp->max_length;
}
else
{
ct.colWidth = std::numeric_limits<int32_t>::max();
}
ct.precision = 0;
ac->resultType(ct);
}