iframe-proxy

groeneai · 2026-06-01T15:02:31Z

After a server restart (or DETACH DATABASE / ATTACH DATABASE), a second DROP TABLE on an already-dropped table produces a confusing self-suggesting hint:

Table default.t0 does not exist. Maybe you meant default.t0?. (UNKNOWN_TABLE)

The async-load pipeline populates DatabaseOrdinary::startup_table (and load_table), but DatabaseWithOwnTablesBase::detachTableUnlocked only erases from tables. The stale name survives in startup_table, DatabaseOrdinary::getAllTableNames keeps reporting it, and TableNameHints matches the just-dropped name against itself.

Make detachTableUnlocked virtual and override it in DatabaseOrdinary so that it also erases the entry from startup_table and load_table. The override fires through every detach/drop path that calls into the base class implementation, so Ordinary, Atomic, and Replicated are all fixed (Atomic and Replicated inherit from DatabaseOrdinary).

A stateless regression test reproduces the bug via DETACH DATABASE + ATTACH DATABASE, which re-runs the same TablesLoader path as a server restart and is enough to populate startup_table without needing the integration-test harness. The test fails on master HEAD without the patch (BAD: stale startup_table entry leaked into hint) and passes with the patch (OK); it was looped 20x locally without flakes. Legitimate hints to existing tables (typo bet for table beta) are preserved.

Changelog category (leave one):

Bug Fix (user-visible misbehavior in an official stable release)

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Fix confusing "Maybe you meant X?" hint after a server restart (or DETACH/ATTACH DATABASE), where dropping an already-dropped table would suggest the just-dropped name as the alternative. The async-load tasks are now cleared from DatabaseOrdinary::startup_table and load_table on detach.

Documentation entry for user-facing changes

Documentation is written (mandatory for new features)

Closes #91777.

Version info

Merged into: 26.7.1.233

groeneai · 2026-06-01T15:03:03Z

Pre-PR validation gate (session cron:clickhouse-ci-task-worker:20260601-141500)

a) Deterministic repro? Yes. With unmodified master HEAD (or the patch reverted):

CREATE DATABASE db_91777;
CREATE TABLE db_91777.t (c Int) ENGINE = MergeTree ORDER BY tuple();
DETACH DATABASE db_91777;
ATTACH DATABASE db_91777;
DROP TABLE db_91777.t SYNC;
DROP TABLE db_91777.t SYNC;
-- Table db_91777.t does not exist. Maybe you meant db_91777.t?. (UNKNOWN_TABLE)

The original repro from the issue (CREATE + server restart + double DROP) was also confirmed locally and produces the same message.

b) Root cause explained? DatabaseOrdinary::loadTableFromMetadataAsync populates load_table[name] and DatabaseOrdinary::startupTableAsync populates startup_table[name] during the TablesLoader startup path. DatabaseWithOwnTablesBase::detachTableUnlocked removes only from tables, because startup_table is a DatabaseOrdinary-level member that the base class does not know about. The stale entry survives in startup_table until shutdown, DatabaseOrdinary::getAllTableNames reports it, and TableNameHints::getHintForTable matches the just-detached name against itself (edit distance 0).

c) Fix matches root cause? The override erases the stale entries in startup_table and load_table at exactly the call site that already takes the database mutex. Not a band-aid: the hint logic (PR #95116 by matt-metivier, already approved by alexey-milovidov) is the symptom fix; this PR fixes the upstream leak that produces the bad input to the hint logic. The two changes are complementary.

d) Test intent preserved / new test added? New stateless test 04304_91777_drop_after_attach_database_no_self_hint.sh added, no existing test modified or weakened.

e) Both directions demonstrated?

Without the fix (detachTableUnlocked reverted to a thin wrapper over the base): test prints BAD: stale startup_table entry leaked into hint followed by the misleading server response.
With the fix: test prints OK. Looped 20/20 without flakes.

f) Fix is general? The override fires through every detach path that calls DatabaseWithOwnTablesBase::detachTableUnlocked or the DatabaseOrdinary:: qualified call:

DatabaseWithOwnTablesBase::detachTable (DETACH TABLE for Ordinary / Atomic / Replicated)
DatabaseAtomic::detachTable and DatabaseAtomic::dropTableImpl, which both call DatabaseOrdinary::detachTableUnlocked explicitly
DatabaseOnDisk::dropTable and DatabaseOnDisk::detachTablePermanently, which call detachTable
DatabaseOnDisk::renameTable (Ordinary-to-Ordinary), which calls detachTable

One known gap: DatabaseAtomic::renameTable performs the in-memory detach via a local lambda that bypasses detachTableUnlocked. Rename within an Atomic database therefore leaves the stale startup_table["old_name"] entry behind, which can still inflate the hint pool for unrelated lookups until the database is restarted. This is a narrower secondary issue (renaming an async-loaded table within Atomic) that I left out of scope here; happy to follow up if the reviewer wants it folded in. The DROP/DETACH path called out in the issue is fully covered.

clickhouse-gh · 2026-06-01T15:05:42Z

Workflow [PR], commit [a8a201d]

Summary: ✅

Performance Comparison: Performance dashboard

AI Review

Summary

This PR clears stale async-load bookkeeping from DatabaseOrdinary::startup_table and load_table when a table is detached, and also covers the DatabaseAtomic::renameTable detach lambda that bypasses detachTableUnlocked. That matches the linked issue's root cause: TableNameHints reads getAllTableNames, so removed table names must not remain in the async-load maps after restart or DETACH DATABASE / ATTACH DATABASE. I did not find any remaining correctness issues in the current diff; the earlier bot findings about test fail-fast behavior and the Atomic rename path are addressed, and the latest Praktika report for a8a201d5e51b14e3f6ebbae4f7dd3bd8fbd9712b shows no failed checks.

Final Verdict

Status: ✅ Approve

PedroTadim · 2026-06-07T08:20:43Z

@groeneai many tests failed, check.

groeneai · 2026-06-10T19:41:26Z

Checked. The failures on the previous commit (9431e00) were all explained by one issue in the regression test, now fixed in 83cc50e. Breakdown:

CI ledger, covered SHA 9431e00:

Stateless tests (...) x6 (amd_asan_ubsan distributed, amd_tsan parallel, amd_msan WasmEdge parallel, amd_msan flaky, arm_binary parallel) failing on 04304_91777_drop_after_attach_database_no_self_hint: test bug. The hint check pattern Maybe you meant.*\.t\? also matched a legitimate cross-database hint in parallel mode (Maybe you meant test_<rand>.t?). The source fix works; the test mis-flagged it. Fixed in 83cc50e (exact self-match + fail-fast). Detail on the inline thread.
Server died x4 in flaky-check / targeted jobs: infrastructure noise, not this PR. This marker appears 381 times across 63 distinct PRs in the last 14 days. The server log for our run shows only clean-shutdown messages (no crash, no OOM, no sanitizer report).
Mergeable Check / CH Inc sync / PR: aggregator jobs reflecting the above, not independent failures.

The test never failed on master or any other PR (only this PR's 2026-06-01 run). New CI is running on 83cc50e.

session: cron:clickhouse-worker-slot-23:20260610-184200

groeneai · 2026-06-10T19:41:48Z

Pre-PR validation gate (fix-up commit `83cc50e`)

#	Question	Answer
a	Deterministic repro?	Yes. Running the test body against a live server: a synthetic self-suggestion string (`Maybe you meant ${DB}.t?`) is flagged `BAD`; a deliberately broken setup command (bad table engine) makes the script exit non-zero with no `OK` (fail-fast); a clean run prints `OK` 20/20.
b	Root cause explained?	The 6 stateless failures came from the test, not the source fix. The check used `grep -qE 'Maybe you meant.*\.t\?'`. In parallel mode the hint system legitimately cross-suggests a concurrent test's table (`Maybe you meant test_n3czwljm.t?`, confirmed in the arm_binary report). That loose regex matched the cross-DB hint and printed `BAD`, even though the fix correctly stopped the self-suggestion. CI reruns passed 35/35, consistent with a parallel-collision false positive.
c	Fix matches root cause?	Yes. The check now matches exactly `Maybe you meant ${DB}.t?` (self-suggestion to the just-dropped table), so cross-database hints no longer trip it. Separately, `set -euo pipefail` + cleanup trap close the silent-setup-bypass hole (the earlier bot/reviewer note); the expected second `DROP TABLE` stays guarded with `
d	Test intent preserved / new tests added?	Preserved. The test still asserts the exact bug (a self-suggestion to `${DB}.t`) and is now stricter: a failed setup can no longer reach a false `OK`. It only stops flagging the legitimate cross-DB case it was never meant to catch.
e	Both directions demonstrated?	Yes. Clean run -> `OK` (20/20). Broken setup -> fail-fast, no false `OK`. Synthetic self-suggestion -> `BAD`.
f	Fix is general, not a narrow patch?	N/A (test-only change; the source fix in `DatabaseOrdinary::detachTableUnlocked` is correct and unchanged, confirmed by the cross-DB hint pointing away from self).

Session id: cron:clickhouse-worker-slot-23:20260610-184200

After server restart (or DETACH/ATTACH DATABASE) the async-load pipeline populates `DatabaseOrdinary::startup_table` and `load_table`, but `DatabaseWithOwnTablesBase::detachTableUnlocked` only removes the entry from `tables`. The stale entry in `startup_table` survives, and `DatabaseOrdinary::getAllTableNames` reports it as a known name. The next failed lookup of the just-detached name asks `TableNameHints` for a suggestion, which then matches the dropped name against itself and produces the confusing Table X.Y does not exist. Maybe you meant X.Y? Make `detachTableUnlocked` virtual and override it in `DatabaseOrdinary` to also erase the entries from `startup_table` and `load_table`, via a shared `eraseAsyncLoadState` helper. The override fires through every detach/drop path that calls into the base class implementation: `DatabaseWithOwnTablesBase::detachTable`, `DatabaseAtomic::detachTable`, `DatabaseAtomic::dropTableImpl`, and `DatabaseOnDisk::dropTable` / `detachTablePermanently` / `renameTable` (via `detachTable`). `DatabaseAtomic::renameTable` does not go through `detachTableUnlocked`: it detaches via a local lambda that erases `tables`/`table_name_to_path` directly. Call `eraseAsyncLoadState` from that lambda too, otherwise a `RENAME TABLE` on an async-loaded Atomic/Replicated table leaves the old name in `startup_table` and a later typo lookup near the old name still suggests it. Applies to `Ordinary`, `Atomic`, and `Replicated` (all inherit from `DatabaseOrdinary`). Closes ClickHouse#91777. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

groeneai · 2026-06-11T00:44:42Z

Pre-PR validation gate

(For the renameTable fix-up + extended regression test pushed in this revision.)

#	Question	Answer
a	Deterministic repro?	Yes. On a debug build, `CREATE DATABASE db; CREATE TABLE db.alpha (...) ENGINE=MergeTree; DETACH DATABASE db; ATTACH DATABASE db; RENAME TABLE db.alpha TO db.beta;` then `DROP TABLE db.alphx` deterministically prints `Maybe you meant db.alpha?` on the unfixed build (in an isolated DB so no cross-DB hint competes).
b	Root cause explained?	`DETACH/ATTACH DATABASE` re-runs async loading, populating `DatabaseOrdinary::startup_table` with `alpha`. `DatabaseAtomic::renameTable` detaches the source via a local lambda that erases only `tables`/`table_name_to_path`, never going through `detachTableUnlocked`, so `startup_table["alpha"]` survives. `getAllTableNames` returns `tables ∪ startup_table` = `{beta, alpha}`, so a typo one edit from `alpha` is answered with the nonexistent `db.alpha` (issue #91777).
c	Fix matches root cause?	Yes. Extracted the async-load-state erase into `DatabaseOrdinary::eraseAsyncLoadState(name)` and call it from both `detachTableUnlocked` and the Atomic rename `detach` lambda, so the rename path clears `startup_table`/`load_table` for the old name at the exact point it removes it from `tables`. No symptom guard.
d	Test intent preserved / new tests added?	Yes. Added scenario 2 to `04304_91777_drop_after_attach_database_no_self_hint.sh` (RENAME path) alongside the existing DROP scenario; reference updated to `OK\nOK`. The hint check matches the exact `Maybe you meant <db>.<name>?` string so a legitimate cross-DB hint from a concurrent parallel test is not flagged.
e	Both directions demonstrated?	Yes. Two debug builds from the same tree differing only by this change: scenario 2 prints `BAD: stale startup_table entry leaked into hint after RENAME` on the unfixed build and `OK` on the fixed build. The full test passes 25/25 on the fixed build.
f	Fix is general, not a narrow patch?	Yes. Checked sibling paths: the Ordinary path (`DatabaseOnDisk::renameTable`) already routes through `detachTable` -> `detachTableUnlocked`, so it is covered; `DatabaseReplicated::renameTable` delegates to `DatabaseAtomic::renameTable`, so it is covered by the same lambda fix. The shared helper means no detach/rename path can bypass the cleanup. Fix is at the source (where the name is removed from `tables`), not a guard at the hint site.

Session id: cron:clickhouse-worker-slot-9:20260610-234100

Stateless test for issue ClickHouse#91777. It uses DETACH DATABASE + ATTACH DATABASE to re-trigger the async-load path that populates startup_table without a full server restart, then checks two paths that previously leaked a no-longer-present name into a table-not-found hint: 1. DROP TABLE: after dropping an async-loaded table, a lookup of a name one edit away must not be answered with a hint pointing at the dropped table. 2. RENAME TABLE: after renaming an async-loaded table away, a lookup one edit from the old name must not suggest the old name. Both scenarios use a near-miss name rather than the exact dropped name, so they reproduce independently of the exact-name self-suggestion that getHintForTable already suppresses, and so each scenario fails on master without the fix. The hint check is database-qualified so a legitimate cross-database hint from a concurrent parallel test is not mistaken for the bug. Setup runs under set -euo pipefail with a cleanup trap so a failed setup command cannot reach a false OK. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

groeneai · 2026-06-11T01:02:17Z

Pre-PR validation gate (commit `eaee452`)

This commit strengthens the regression test so both scenarios fail on current master and pass with the fix. Context: the symptom-layer fix #95116 ("Fix bad hints suggesting the exact same name", merged 2026-06-04) now suppresses the exact-name self-suggestion Maybe you meant <db>.t?. The previous test asserted only that exact-name case, so on current master it passed regardless of this PR's fix and Bugfix validation (functional tests) reported "Failed to reproduce the bug". This PR's fix targets a different, still-reproducing defect: a removed name (dropped or renamed) lingering in startup_table/load_table and being offered as a near-miss hint, which #95116 does not guard.

#	Question	Answer
a	Deterministic repro?	Yes. On master (debug, includes #95116): `CREATE DATABASE db; CREATE TABLE db.tbl0 ... MergeTree; DETACH DATABASE db; ATTACH DATABASE db; DROP TABLE db.tbl0 SYNC; DROP TABLE db.tbl1 SYNC` → `Table db.tbl1 does not exist. Maybe you meant db.tbl0?` (suggests the dropped table). Same with `RENAME TABLE db.alpha TO db.beta` then `DROP TABLE db.alphx SYNC` → suggests the renamed-away `alpha`.
b	Root cause explained?	`DatabaseOrdinary::getAllTableNames` unions `tables` with the async-load `startup_table` map. `detachTableUnlocked` (DROP/DETACH) removed only from `tables`; `DatabaseAtomic::renameTable`'s local detach lambda likewise left the old name in `startup_table`. `TableNameHints::getAllRegisteredNames` reads `getAllTableNames`, so a removed name remained a hint candidate. Levenshtein(`tbl0`,`tbl1`)=1 ≤ mistake_factor=2, and `tbl0`≠`tbl1`, so #95116's exact-name guard does not fire and the dropped name is suggested.
c	Fix matches root cause?	Yes. `DatabaseOrdinary::detachTableUnlocked` is overridden to erase the name from `startup_table`/`load_table` (shared `eraseAsyncLoadState` helper), and `DatabaseAtomic::renameTable`'s detach path calls the same helper. The base `detachTableUnlocked` is made virtual so Ordinary/Atomic/Replicated all route through the cleanup. The removed name is no longer a hint candidate.
d	Test intent preserved / new tests added?	Strengthened. The test still covers both DROP and RENAME, but each scenario now uses a near-miss lookup (`tbl1`→dropped `tbl0`; `alphx`→renamed-away `alpha`) instead of an exact-name self-suggestion. The exact-name version passed on master independent of this fix (masked by #95116) and validated nothing; the near-miss version fails on master for both scenarios and validates both the DROP-path and RENAME-path fixes.
e	Both directions demonstrated?	Yes, through the test harness. No-fix master binary (Build ID `ebc16ed5`): both scenarios print `BAD` (test fails). With-fix binary (Build ID `312caa8e`): `OK\nOK`, 15/15 runs, no flakiness. Also confirmed legitimate hints are preserved (typo for an existing table still suggests it) and an async-loaded existing table is still suggested (fix does not over-erase).
f	Fix is general, not a narrow patch?	Yes. The cleanup is at the source of the leak (the detach/rename paths that mutate `tables`), not a guard at the hint site. Making the base `detachTableUnlocked` virtual covers all `DatabaseWithOwnTablesBase` subclasses; the Atomic rename path is handled explicitly since it bypasses `detachTableUnlocked`. `getAllTableNames`'s only other consumer (`DatabaseReplicated` debug ZK-diff) also benefits from the corrected name set.

Session id: cron:clickhouse-worker-slot-20:20260611-002300

groeneai · 2026-06-11T06:13:24Z

CI finished on `eaee452d47d7`. Both failures are chronic/infra, not caused by this PR (which touches `DatabaseOrdinary.cpp` / `DatabaseAtomic.cpp` async-load cleanup + the regression test):

`Stateless tests (arm_asan_ubsan, azure, sequential)` — `Server died` / `AddressSanitizer` (STID 3772-3b00): the Azure arm_asan_ubsan mass outage of 2026-06-10/11 (ASan secondary-allocator OOM). Not PR-related.
`Stress test (arm_ubsan)` — `Hung check failed, possible deadlock found`: chronic Stress arm_ubsan hung-check noise, 24 PRs / 44 master in 30d. Not specific to this PR.

The renameTable async-load-state cleanup gap flagged by the bot is addressed in the current HEAD (shared `eraseAsyncLoadState` helper called from both `detachTableUnlocked` and the `DatabaseAtomic::renameTable` detach lambda), with an Atomic-rename regression case. Ready for review.

groeneai · 2026-06-11T06:57:01Z

CI summary for HEAD eaee452d47d7 — all red marks are non-PR-caused (infra / chronic trunk), the PR's own checks are green:

Stateless tests (arm_asan_ubsan, azure, sequential) — "Server died" + AddressSanitizer: CHECK failed: sanitizer_allocator_secondary.h:199 (STID 3772-3b00). This is the known 2026-06-10/11 azure ASan internal LargeMmapAllocator OOM outage (no ClickHouse frames in the stack); it hit ~40 unrelated tests / 50+ PRs + master in the same window. Not caused by this PR (which only clears async load tasks on detach).
Stress test (arm_ubsan) — "Hung check failed, possible deadlock found". Chronic stress-test infra finding across 12+ unrelated PRs in 14d. Tracked separately.
Fast test, Style check, Bugfix validation (functional), Build, and all other jobs pass or skip.

CH Inc sync red is the internal CH mirror sync, expected on fork PRs (not a test).

PedroTadim · 2026-06-16T07:18:25Z

@groeneai merge with master

groeneai · 2026-06-16T08:40:44Z

Merged master into the branch in 6c9ca50. Conflict-free; the fix (shared eraseAsyncLoadState from detachTableUnlocked + the DatabaseAtomic::renameTable detach lambda) and the 04304 regression are unchanged. Rebuilt against current master and both 04304 scenarios still pass. Fresh CI triggered.

groeneai · 2026-06-16T14:37:29Z

CI finished on the merge commit (6c9ca50). The two non-infra checks that show red are not caused by this PR (which touches only DatabaseAtomic/DatabaseOrdinary async-load cleanup + the 04304 test):

Stress test (arm_release) — Last stored last_written_position in meta file ... is bigger than current last_written_pos (StorageFileLog, STID 2733-34dd). Pre-existing trunk bug in StorageFileLog, unrelated to async-load detach; surfaced under stress (Thread Fuzzer + RandomQueryKiller) on 2 unrelated PRs in 30d, 0 on master. Tracked and fixed separately in Fix FileLog crash on delete+recreate reusing the same inode #107617.
CH Inc sync — internal mirror check; does not run for fork PRs.

Finish Workflow is green and all real test jobs passed.

groeneai · 2026-06-18T00:55:22Z

CI finished on the current HEAD (6c9ca50, the 2026-06-16 auto master-merge; the two real fix/test commits 22658b4 + eaee452 are unchanged). The two fix/test commits are clean; the only red is a pre-existing trunk failure unrelated to this PR:

Stress test (arm_release) / Logical error: Last stored last_written_position in meta file ... is bigger than current last_written_pos (122 > 0) (STID 2733-34dd): a StorageFileLog meta-file logical error in the engine, not in the DatabaseOrdinary/DatabaseAtomic detach path this PR touches. It is a known recurring trunk bug (also seen on master and on unrelated PRs), tracked separately. Report: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=106238&sha=6c9ca50a9d74d9243c73969d74ea8573f4cd2f81&name_0=PR&name_1=Stress%20test%20%28arm_release%29
Mergeable Check / PR: aggregators reflecting the Stress red above.

The PR-own checks (Bugfix validation of 04304, Stateless, Builds) are green. Closes #91777.

tuanpach · 2026-06-22T02:05:53Z

+StoragePtr DatabaseOrdinary::detachTableUnlocked(const String & table_name)
+{
+    eraseAsyncLoadState(table_name);
+    return DatabaseWithOwnTablesBase::detachTableUnlocked(table_name);


@groeneai Should we eraseAsyncLoadState after DatabaseWithOwnTablesBase::detachTableUnlocked?
In case DatabaseWithOwnTablesBase::detachTableUnlocked throws an exception?

Good catch, fixed in 36cf155. The base DatabaseWithOwnTablesBase::detachTableUnlocked throws UNKNOWN_TABLE before mutating anything when the table is absent, so erasing first would clear the async-load state for a table that was never detached. Now the base detach runs first and eraseAsyncLoadState only runs on success (both map erases are noexcept). The DatabaseAtomic::renameTable detach lambda was already correct: it erases after tables.erase/table_name_to_path.erase. 04304 still passes 20/20.

DatabaseOrdinary::detachTableUnlocked erased startup_table/load_table before calling DatabaseWithOwnTablesBase::detachTableUnlocked. The base throws UNKNOWN_TABLE before mutating anything when the table is absent, so on that throw the async-load state was cleared for a table that was never detached. Call the base first and erase only on success. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

groeneai · 2026-06-22T06:39:55Z

CI ledger — covered SHA `36cf1552a00b`

CI fully finished on this HEAD (Finish Workflow + Mergeable Check complete, no checks queued/in_progress). This HEAD is the eraseAsyncLoadState exception-safety reorder (base detach first, erase async-load state only on success) addressing @tuanpach's review.

The PR touches only src/Databases/{DatabaseAtomic.cpp,DatabaseOrdinary.cpp,DatabaseOrdinary.h,DatabasesCommon.h} (async-load-state cleanup on detach/rename) plus the 04304 regression test. One red check, not PR-caused:

Stress test (arm_debug) / "Hung check failed, possible deadlock found" — chronic Stress Thread-Fuzzer hung-check, not specific to this PR. 30d CIDB: 278 master hits + 20+ unrelated PRs (e.g. 101039, 107567, 104396, 80416, 91836, 105321, 107899, 99495). The hung stacktrace is executeASTFuzzerQueries -> PipelineExecutor::executeImpl waiting under ThreadFuzzer injection in jemalloc; zero async-load / detach / rename frames. Tracked separately (chronic Hung-check deadlock tracker).
PR (aggregator) — rollup of the above; no distinct failure.

No PR-caused failures. Ready for review.

tuanpach · 2026-06-23T14:21:30Z

@groeneai

Check CI failures. Any PRs fixing them?

groeneai · 2026-06-23T14:45:49Z

@tuanpach The only red is Stress test (arm_debug) -> "Hung check failed, possible deadlock found" (report). The PR check is just its rollup; every other job is green.

It is not PR-caused and not actually a deadlock. The hung stack is the server-side AST fuzzer running a cancelled-but-still-executing fuzzed query past the 90s hung-check window:

ThreadPoolImpl::wait
PipelineExecutor::executeImpl
CompletedPipelineExecutor::execute
DB::executeASTFuzzerQueries

No frame touches this PR's code (the DatabaseOrdinary/DatabaseAtomic async-load cleanup). It is a chronic trunk failure across every stress sanitizer lane: on arm_debug alone, 49 distinct PRs hit it in the last 30d vs only 2 master.

PRs fixing it:

Make server-side AST fuzzer respect KILL, timeout and shutdown #107640 (@Algunenano, merged 2026-06-18) makes the server-side fuzzer respect KILL/timeout/shutdown, but only between loop iterations, so an in-flight granule write can still overrun the hung-check window. That is why it still recurs.
Interrupting the in-flight fuzzed query (the remaining gap) is under discussion in Hung check failed, possible deadlock found #107941.

The PR is otherwise green.

clickhouse-gh · 2026-06-29T01:22:41Z

LLVM Coverage Report

Changed lines: Changed C/C++ lines covered by tests: 14/14 (100.00%) | Lost baseline coverage: none · Uncovered code

Full report · Diff report

groeneai mentioned this pull request Jun 1, 2026

Confusing drop message after server restart #91777

Closed

PedroTadim added the can be tested Allows running workflows for external contributors label Jun 1, 2026

clickhouse-gh Bot added the pr-bugfix Pull request with bugfix, not backported by default label Jun 1, 2026

clickhouse-gh Bot reviewed Jun 1, 2026

View reviewed changes

Comment thread tests/queries/0_stateless/04304_91777_drop_after_attach_database_no_self_hint.sh

clickhouse-gh Bot reviewed Jun 10, 2026

View reviewed changes

Comment thread src/Databases/DatabaseOrdinary.cpp

groeneai force-pushed the groeneai/fix-91777-startup-table-leak branch from 83cc50e to 6ea3728 Compare June 11, 2026 00:43

groeneai force-pushed the groeneai/fix-91777-startup-table-leak branch from 6ea3728 to eaee452 Compare June 11, 2026 01:01

Merge branch 'master' into groeneai/fix-91777-startup-table-leak

6c9ca50

tuanpach reviewed Jun 22, 2026

View reviewed changes

tuanpach approved these changes Jun 23, 2026

View reviewed changes

clickhouse-gh Bot assigned tuanpach Jun 23, 2026

Merge branch 'master' into groeneai/fix-91777-startup-table-leak

a8a201d

alexey-milovidov added this pull request to the merge queue Jun 29, 2026

Merged via the queue into ClickHouse:master with commit 042af6d Jun 29, 2026
174 checks passed

robot-ch-test-poll3 added the pr-synced-to-cloud The PR is synced to the cloud repo label Jun 29, 2026

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!

Conversation

groeneai commented Jun 1, 2026 • edited by robot-ch-test-poll3 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changelog category (leave one):

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Documentation entry for user-facing changes

Version info

Uh oh!

groeneai commented Jun 1, 2026

Pre-PR validation gate (session cron:clickhouse-ci-task-worker:20260601-141500)

Uh oh!

clickhouse-gh Bot commented Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

AI Review

Summary

Final Verdict

Uh oh!

Uh oh!

PedroTadim commented Jun 7, 2026

Uh oh!

groeneai commented Jun 10, 2026

Uh oh!

groeneai commented Jun 10, 2026

Pre-PR validation gate (fix-up commit 83cc50e)

Uh oh!

Uh oh!

groeneai commented Jun 11, 2026

Pre-PR validation gate

Uh oh!

groeneai commented Jun 11, 2026

Pre-PR validation gate (commit eaee452)

Uh oh!

groeneai commented Jun 11, 2026

Uh oh!

groeneai commented Jun 11, 2026

Uh oh!

PedroTadim commented Jun 16, 2026

Uh oh!

groeneai commented Jun 16, 2026

Uh oh!

groeneai commented Jun 16, 2026

Uh oh!

groeneai commented Jun 18, 2026

Uh oh!

tuanpach Jun 22, 2026

Choose a reason for hiding this comment

Uh oh!

groeneai Jun 22, 2026

Choose a reason for hiding this comment

Uh oh!

groeneai commented Jun 22, 2026

CI ledger — covered SHA 36cf1552a00b

Uh oh!

tuanpach commented Jun 23, 2026

Uh oh!

groeneai commented Jun 23, 2026

Uh oh!

clickhouse-gh Bot commented Jun 29, 2026

LLVM Coverage Report

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

groeneai commented Jun 1, 2026 •

edited by robot-ch-test-poll3

Loading

clickhouse-gh Bot commented Jun 1, 2026 •

edited

Loading

Pre-PR validation gate (fix-up commit `83cc50e`)

Pre-PR validation gate (commit `eaee452`)

CI ledger — covered SHA `36cf1552a00b`