Alexander Tokmakov

Please share the relevant part of server log as text (not as screenshot) ``` zgrep -Fa "Fatal" /var/log/clickhouse-server/clickhouse-server* ```

May be related to #35956, cc: @Algunenano

> @tavplubix let's revert the changes related to the DNS cache ASAP. It's not clear what is the reason and what to revert. #37827 does not seem to be related...

Does it allow (almost) arbitrary writes into [Zoo]Keeper? It may be too dangerous, see the discussion in https://github.com/ClickHouse/ClickHouse/pull/37596

I like the third option and we can also combine it with the first one (disable the feature if sandbox path is not configured) just in case. Yep, let's use...

Hm, I realized that the same issue is possible when creating `KeeperMap` table using `CREATE ON CLUSTER`: it will generate UUID on initiator and query will fail on all hosts...

Another option is to use pair (`ServerUUID::get()`, `table_id.uuid`) as globally unique identifier

@qoega, it's not ok that this test makes BC check fail, we should not simply disable it @kitaisreal has to fix it and backport fix to this branch See #35156

Seems like some exception safety issues are still there: https://s3.amazonaws.com/clickhouse-test-reports/0/3a0581e99034c1e985b4e799f16d04baf3cbf037/stress_test__ubsan_.html ``` /var/log/clickhouse-server/clickhouse-server.err.log:2022.09.05 11:36:35.076003 [ 62969 ] {} BaseDaemon: ######################################## /var/log/clickhouse-server/clickhouse-server.err.log:2022.09.05 11:36:35.076398 [ 62969 ] {} BaseDaemon: (version 22.9.1.1 (official build),...

Dependency between MV and its source/target tables is not a loading dependency. Currently we can successfully load MV, source and target tables independently in parallel and there's no reason to...