https://s3.amazonaws.com/clickhouse-test-reports/0/a9bcd022d5f4a5be530595dbfae3ed177b5c1972/fuzzer_astfuzzermsan/report.html

@azat I reverted the PR ... I think the problem is that the generated query reads 9 quintillion rows (9223372036854775807 == VAR_UINT_MAX). Not realistic for sure, but instead of disallowing this in the AST fuzzer it would be better to make the code more robust. What about doing a sanity check a la writeVarUInt(written_rows > VARUINT_MAX : 0 : written_rows, out); in ProgressValues::write()?

I reverted the PR ... I think the problem is that the generated query reads 9 quintillion rows (9223372036854775807 == VAR_UINT_MAX). Not realistic for sure, but instead of disallowing this in the AST fuzzer it would be better to make the code more robust. What about doing a sanity check a la writeVarUInt(written_rows > VARUINT_MAX : 0 : written_rows, out); in ProgressValues::write()?

Yep, makes total sense - #48154