There is no need to capture query AST for the status_info_to_query_log,
since callers already captured it anyway.
gcc10 reports:
../src/Interpreters/executeQuery.cpp: In member function ‘void std::__1::function<_Rp(_ArgTypes ...)>::swap(std::__1::function<_Rp(_ArgTypes ...)>&) [with _Rp = void; _ArgTypes = {DB::IBlockInputStream*, DB::IBlockOutputStream*, DB::QueryPipeline*}]’:
../src/Interpreters/executeQuery.cpp:490:49: error: array subscript 35 is outside array bounds of ‘std::__1::aligned_storage<32, 16>::type [1]’ [-Werror=array-bounds]
490 | auto status_info_to_query_log = [ast](QueryLogElement &element, const QueryStatusInfo &info) mutable
| ^
In file included from ../contrib/libcxx/include/algorithm:644,
from ../contrib/libcxx/include/__string:57,
from ../contrib/libcxx/include/string_view:175,
from ../contrib/libcxx/include/string:504,
from ../src/Common/formatReadable.h:3, from ../src/Interpreters/executeQuery.cpp:1:
../contrib/libcxx/include/functional:1877:60: note: while referencing ‘__tempbuf’
1877 | typename aligned_storage<sizeof(__buf_)>::type __tempbuf;
| ^~~~~~~~~
00956_sensitive_data_masking is still flacky even after #13748 [1].
[1]: https://clickhouse-test-reports.s3.yandex.net/10373/348ef1256ea8fb8f61109c33bbdd28daf46bdc8e/functional_stateless_tests_(debug).html#fail1
The problem is that it uses the following pattern:
clickhouse-client -q ... & # run some query in background
clickhouse-client -q 'show processlist' > log
grep background-query log
But there is no guarantee that the query in background will be executed before `show processlist`:
2020.08.18 02:52:47.916386 [ 26788 ] {98c36d38-f710-4dfb-af8f-61906abc163c} <Debug> executeQuery: (from [::1]:51650) SHOW PROCESSLIST
...
2020.08.18 02:52:47.926854 [ 26756 ] {086c64fa-713b-4f8c-b702-23bfea10a49c} <Debug> executeQuery: (from [::1]:51652) select count() from system.numbers where ignore('find_me_[hidden]')=0 and ignore('fwerkh_that_magic_string_make_me_unique') = 0 FORMAT Null
Fix the test by waiting until the query in backgroud will start, and use
limited numbers + sleepEachRow over system.numbers to reduce CPU usage.
With default index_granularity=8096 CH always reads at least that number
of rows per selected part, but limit is checked afterwards. The optimization
that interrupts execution of queries based on approx number of rows to read
breaks the test. This means that test case is potetntially contains incorrect
limits.
