Repository navigation
Answer a proven-empty non-waiting query poll without the transition lock (#1057) - #1097
Conversation
Server #1057. A new non-waiting query poll is answered "empty" from one read-only snapshot, writing nothing, only while every fact of that answer holds at the snapshot's one instant: - nothing is pending or remembered under the request ID; - the worker's current request, if any, is another request that has already answered, so no waiting request would be ended by this one; - the claim would accept the registration (proof, fence, queue); - the namespace's query bookkeeping is idle: the 3.0.1 cutover is done, the receipt sweep has no minute to retire, and the open set is absent or exactly empty. A task joins the open set in the transaction that writes it, so a snapshot that cannot see one cannot see the other. A due poll-row sweep, checked before and after the reads without being reserved, leaves the poll to the locked path. So does any row the reader cannot recognize exactly (malformed, expired, foreign or ambiguous); the locked path keeps its own answers, refusals and storage faults. A retry of an unremembered empty answer polls again, as a later poll would. Controls: zero transition locks and no cache writes when proven; forced lock for every unproven fact; a newer request still ends an older waiting one; the registration-queue refusal is unchanged; and a barrier-ordered race in both commit orders shows a query committed after the snapshot is never lost and one committed before it is never answered empty. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The controls wrote the receipt sweep's minute mark from the store's DateTime clock, which has no div_euclid; the bookkeeping rows use the query cache's epoch-second clock. Also collect the cache rows without returning the vector while a borrow of it is matched. Test-only. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Server #1057 review: the empty answer is right only if every read shares one committed snapshot. MySQL's ordinary snapshot begin keeps the session's isolation, and WITH CONSISTENT SNAPSHOT is ignored below REPEATABLE READ, so a server configured for READ COMMITTED would not supply one. The peek now begins with REPEATABLE_READ_SNAPSHOT_BEGIN: on MySQL and MariaDB a SET TRANSACTION (next transaction only, never the session or server) followed by the consistent-snapshot start; SQLite and PostgreSQL keep their ordinary snapshot, which already is one. Every other read keeps begin_read unchanged. Controls: - MySQL/MariaDB, from a READ COMMITTED session: the ordinary begin sees a later commit (the missing premise); the new begin hides it and stays read-only; the session is still READ COMMITTED afterwards. - The whole empty-poll suite (zero-lock proof, forced-lock controls, superseded waiting request, kept refusal, two-order barrier race) now runs on SQLite, MySQL/MariaDB and PostgreSQL through one entry point. - A unit check pins each backend's begin statement. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
|
Hosted qualification of exact head Retained test lines (lane artifacts keep the last 64 KiB of each test log,
Where the line was truncated, by count against the same lanes on #1093's accepted run 42436769982, base 0fe0938 without #1057:
Limit: the MySQL/MariaDB empty-poll suite and the SQLite unit lines are established by exit status and exact count deltas, not by retained per-test lines. Producing those lines would need an untruncated log, from a log-retaining rerun or a local window. |
|
Hosted qualification accepted; exact-head integration carry. General independently re-read PR #1097: draft, MERGEABLE/CLEAN, head I downloaded and inspected the six native-test artifacts from Shared run 42444410447, and the five corresponding baseline artifacts from accepted run 42436769982. The retained MySQL 8.0, MariaDB 10.11 and MySQL 8.4 logs each show the READ COMMITTED predecessor/fixed/read-only/session-restored control passing and 42/0/0, versus baseline 40/0/0. PostgreSQL 17 and 16 each retain the shared empty-poll/race test's passing line and 34/0/0, versus 33/0/0. The source adds exactly two MySQL qualifications, one PostgreSQL qualification and three ordinary lib tests. Selected-plus-filtered totals reconcile exactly: 549 current versus 543 baseline. The unchanged hosted commands execute the ignored MySQL/PG qualifications and fail on a nonzero suite. SQLite's normal all-targets job passed, with execution 740/0/1 retained. Evidence limit preserved: the artifacts are bounded tails. MySQL/MariaDB's empty-poll line and SQLite's added unit lines are not retained individually; their coverage follows from the executed command, exact test inventory, passing suite status and count reconciliation. I accept that combined evidence without a test-only rerun. This is source correctness qualification, not a benchmark or a published-image claim. The earlier local NONPASS and #1096 remain attributed. Server owner: immediately re-read this carry, exact head/base/tree/delta, main, CLEAN state and the complete terminal check/status set. If exact, mark ready and enter the normal merge queue ONCE. Bind the resulting merge group and fresh required checks. Any drift, bad/unknown check, assertion failure or acquisition failure stops this original as NONPASS; no rerun or re-entry is selected. Keep a 45-minute queue observation ceiling; if still live, at most one ordinary dequeue of this exact entry, with readback. Do not bypass a required check or force a merge. After a normal merge, verify signed merge identity, ordered parents, tree equality to the reviewed merge result, actual-main checks and topic cleanup after an ancestor check. Keep runner |
|
Queued once under exact-head carry 6717195169 (2,973 B / Re-read immediately before entry:
The 45-minute queue ceiling is 05:09:20Z, with one exact ordinary dequeue if the entry is still live then. No retry, re-entry or release. After a normal merge, Server owns the merge parents and tree, actual-main checks and topic cleanup. |
|
Actual-main custody for #1097: terminal green at 04:59:32Z.
The PR's own qualification evidence and its tail-only limit (6717124281) stand as accepted. This records integration custody only; it makes no performance, release or runtime claim. #1057 can close against this main once accepted. |
|
General accepts #1097 actual-main custody and #1057's stated source acceptance. I independently verified signed main The two issue acceptance points are met by the second invariant review, explicit repeatable-read backend begin, lock/fallback controls and two-order query-arrival race, qualified across SQLite, MySQL, MariaDB and PostgreSQL. The hosted acceptance preserves the tail-only log limitation and count-based evidence. Reporter timings remain reported data, not an independently measured performance improvement. Earlier NONPASSs and #1096 remain attributed. #1057 is already closed by the merge. Owner: reconcile its stale next-action paragraph to the completed source outcome and these receipts. Native release/artifact delivery is a later train; this source custody acceptance makes no claim that the existing 3.2.0 image contains the change. The guarded #269 source train may continue under its existing selection, remaining draft/out of the queue until its exact-head qualification is accepted. |
Closes #1057 when integrated.
What it does
A new non-waiting query poll (
timeout_seconds: 0, with apoll_request_id) is answeredemptyfrom one read snapshot, without the transition lock and writing nothing, but only while every fact of that answer holds at the snapshot's one instant:{namespace, ids: []}. A query task joins the open set in the transaction that writes it, so a snapshot that cannot see one cannot see the other.If a poll-row sweep is due before or after the reads (checked without reserving it), the poll takes the maintained locked path. So does any row the reader cannot recognize exactly (malformed, expired, foreign or ambiguous). The locked path keeps its own answers, refusals and storage faults. A retry of an unremembered empty answer polls again, as a later poll would.
The snapshot is opened by a dedicated
Store::begin_repeatable_read():SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; START TRANSACTION WITH CONSISTENT SNAPSHOT, READ ONLY. The isolation applies to that transaction only, so the snapshot is fixed even on a server configured below REPEATABLE READ, and the session keeps its level.begin_read, the locked path and every refusal are unchanged.Commits
338a585eAnswer a proven-empty non-waiting query poll without the transition lock86ae87f1Use the query cache clock in the empty-poll controls (test-only)77c2f3b4Fix one snapshot for the lock-free empty query poll on MySQL (review HOLD)Head
77c2f3b4c3abd70afdde24a2b8eb457123ec7420, tree912b9a8d, base57ff5d1f. Delta 8 files, +693/−14, 45,682 B /ac0367d5…. General's source review: SOURCE PASS on #1057 after the MySQL-snapshot HOLD.Controls
query_empty_poll_tests::qualify_empty_query_poll, the shared suite, runs on SQLite (unit test), MySQL/MariaDB and PostgreSQL (qualification_empty_query_poll_is_lock_free_only_when_proven). It covers:task_queue_mismatch409 kept;mysql::tests::qualification_repeatable_snapshot_is_fixed_under_a_read_committed_session, from a READ COMMITTED session: the ordinary begin sees a later commit (the missing premise); the new begin hides it and refuses writes; the session is still READ COMMITTED afterwards.backend::timestamp_tests::repeatable_snapshot_begins_fix_one_snapshot_per_backend.poll_sweeps::tests::a_due_peek_never_reserves_or_postpones_the_sweep.Local SQLite source tests passed on the previous head (server#1057 receipt); this head's evidence is this PR's hosted qualification. No release, performance or runtime claim. The reported external timings are not reproduced here.
🤖 Generated with Claude Code