**Summary**
After upgrading a host that is just a collection `Distributed` tables to 20.4.X and 20.5.2.7, we observe the new `MemoryTracking` setting increasing substantially during writes, leading to individual writes and reads yielding exceptions: ```Memory limit (total) exceeded: would use 28.28 GiB (attempt to allocate chunk of 4197840 bytes), maximum: 28.28```

System metrics show that no actual memory is being allocated to the same size.
<img width="993" alt="Screen Shot 2020-07-19 at 12 23 59 PM" src="https://user-images.githubusercontent.com/1189446/87883721-229e7280-c9be-11ea-851b-0e1511cc10bb.png">

Please let me know if there is any additional context, diagrams, or statements I should provide. I'm interested in knowing how to correlate the total `MemoryTracking` metric to anything else since system memory does not reflect the metric at all.

**Context**
This host has four different `Distributed` tables that are written to via the HTTP interface with `insert_distributed_sync=1` set.
The host itself has no local tables.

The hosts with the downstream local tables are all 20.5.2.7.

We have downgraded the `Distributed` host in question back to 20.3.9.70 in order to continue writing to the clusters.
assert(unit.status == READY_TO_INSERT);
            
            unit.segment.resize(0);
            const bool have_more_data = file_segmentation_engine(original_buffer,
                unit.segment, min_chunk_bytes);
            unit.is_last = !have_more_data;
            unit.status = READY_TO_PARSE;
            scheduleParserThreadForUnitWithNumber(segmentator_ticket_number);
            ++segmentator_ticket_number;
            if (!have_more_data)
            {
                break;
            }
        }
    }
    catch (...)
    {
        onBackgroundException();
    }
}
void ParallelParsingBlockInputStream::parserThreadFunction(size_t current_ticket_number)
{
    try
    {
        setThreadName("ChunkParser");
        const auto current_unit_number = current_ticket_number % processing_units.size();
        auto & unit = processing_units[current_unit_number];
        /*
         * This is kind of suspicious -- the input_process_creator contract with
         * respect to multithreaded use is not clear, but we hope that it is