`DNSResolver::Impl::Impl()` was eagerly running
`Poco::Net::DNS::hostName()` followed by `hostByName` on the local
hostname. The cached result is consumed only by
`updateHostNameAndAddresses` (a server-only periodic task) and by
`getHostName`, which has its own lazy fallback. Yet the work happened
inside a process-wide Meyers singleton, so every program that calls
`DNSResolver::instance` paid the cost — including `clickhouse-client`,
`-local`, `-keeper`, and `-disks`.
When the local hostname could not be resolved (a normal occurrence on
fresh CI/EC2 runners where the auto-generated `ip-X-X-X-X` name is
neither in `/etc/hosts` nor served by the VPC resolver), the catch
block in the constructor logged a stack trace at error level. The
fast-test runner treats any stderr output as a test failure, so this
infrastructure flake masqueraded as a per-test failure.
Move the eager priming out of the singleton constructor:
* `Impl::Impl` is now defaulted; non-server programs no longer touch
the local hostname during startup.
* `programs/server/Server.cpp` calls `updateHostNameAndAddresses`
explicitly before starting `DNSCacheUpdater`, so the first cache
tick on a healthy server still sees a populated value and does not
spuriously emit `IPs of host name X have been changed`.
Behaviour from PR #93726 (cluster config reload on host IP change) is
preserved — verified by `test_reload_cluster_config_if_host_address_change`,
which still passes.
Failing fast tests in https://github.com/ClickHouse/ClickHouse/pull/103689
(report:
https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=103689&sha=3a119a57269adba3557204ce44e58a65054e31df&name_0=PR&name_1=Fast%20test
)
include `Tests/02001_hostname_test`, `Tests/03213_deep_json`,
`Tests/03638_merge_max_dynamic_subcolumns_in_compact_part`, and
`Tests/02433_default_expression_operator_in`, all hitting the same
`Cannot resolve host (ip-172-31-33-233)` startup path.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Drop two heuristics added during PR development that override explicit
user-configured ratios on small systems:
- Forced uplift of `max_server_memory_usage_to_ram_ratio` to `0.95` when
RAM < 4 GiB.
- Forced cap of `merges_mutations_memory_usage_to_ram_ratio` to `0.1`
when RAM < 4 GiB.
Per reviewer feedback: too ad-hoc, removing for now. The remaining
auto-tuning (Parquet watermark, INSERT block size, background pool,
jemalloc dirty decay) is sufficient for the low-memory case and does not
silently override explicit operator settings.
After merging master, two new call sites in `programs/server/Server.cpp`
(lines 2847-2848) pass only three arguments to `MergeTreeSettings::sanityCheck`,
which this branch expanded to take four arguments (adding the
`background_pool_auto_lowered` flag).
Pass `global_context->wasBackgroundPoolAutoLowered()` at both call sites so
the startup-time sanity check agrees with the per-table checks in
`MergeTreeData.cpp`.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
- Set a 30-second `setReceiveTimeout` in the main WebSocket I/O loop to
prevent a malicious client from blocking the handler thread by trickling
bytes after `poll` indicates readability. On timeout, the connection is
terminated (not continued), avoiding protocol desync from partial frame
reads.
- Fix the SSH `#else` branch error message to also mention non-Linux
platforms, since the guard is `USE_SSH && defined(OS_LINUX)`.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
These are valid non-degraded states for read-only arrays, so we should
not warn about them.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
- Check `/sys/block/mdX/md/array_state` in addition to `sync_action` to warn
when an mdraid array is in a non-normal state (degraded, inactive, etc.)
- Add `addOrUpdateWarningMessage` overload accepting `std::optional<PreformattedMessage>`:
passing `nullopt` removes the warning, enabling future periodic checks to
automatically clear stale warnings when conditions resolve.
- New warning type `LINUX_MDRAID_IS_DEGRADED`.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Alexey Milovidov