02362_part_log_merge_algorithm is flaky

[mstetsyuk]

02362_part_log_merge_algorithm is flaky: one, two, three, four.

After two INSERTs followed by an OPTIMIZE, the test expects the part log to only have the following events:

NewPart
NewPart
MergeParts

However, because the test has a race condition with ReplicatedMergeTreeCleanupThread removing stale parts, the part log also includes RemovePart events.

The test can be fixed by adding WHERE event_type IN ('NewPart', 'MergeParts') to filter out stale parts removals (as well as any other potential background events). Alternatively, we can do WHERE event_type != 'RemovePart' to only filter out removals, and still fail if other background events happen.

[tavplubix]

Well done @mstetsyuk, thanks! However, one thing is not clear:

However, because the test has a race condition with ReplicatedMergeTreeCleanupThread removing stale parts, the part log also includes RemovePart events.

There's an old_parts_lifetime setting (8 minutes by default) which delays the removal of stale parts. How is the race condition possible if the test execution time is about 30-40 seconds, and it's much less than 8 minutes? Do we have a bug that causes premature removal of data parts?

[mstetsyuk]

There's an old_parts_lifetime setting (8 minutes by default) which delays the removal of stale parts. How is the race condition possible if the test execution time is about 30-40 seconds, and it's much less than 8 minutes?

@tavplubix, the value of old_parts_lifetime is randomized. In fact, in all the examples that I listed, old_parts_lifetime is set to 10, making it possible for the race condition to manifest itself.