Repository navigation
fix(db): every PostgreSQL call waits its turn; a wait for the connection has its own limit and message (#1216) - #1260
Merged
Conversation
…mit and error (#1216) The metadata and stats queries of PostgresConnection went to the driver directly, past our statement queue. The driver starts their default 30 s timeout while they wait for the connection, so one queued behind a long statement could still cancel it. They now run in the queue too. StatementQueue replaces the two copies of the queue in the PostgreSQL and MySQL wrappers. A statement that waits longer than its limit (2 min) fails with StatementWaitTimeoutException ('Waited 120 s for the connection') and never runs; the statement it waited for is not touched.
…acceptance tests The SQL editor shows 'Query timed out after 30 s' for a statement that ran too long and 'Waited 120 s for the connection' for one that never got the session; the error mapper (and through it MCP) maps the wait to its own message and hint. Tests: after a 57014 cancel the next statement runs on the session; a statement longer than the next one's timeout is not cancelled and the next timeout reaches the driver only when the next statement starts; a bare TimeoutException closes only its own session; a MySQL query waiting 11 s behind another keeps the session; the wait limit fails only the waiting statement.
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Finishes #1216 after #1222, which queued
executeand kept the session on a 57014 cancel.PostgresConnectionsent ~30 calls straight to the driver (tables, columns, PKs, stats,version(), the transaction probe…), past our statement queue. The driver starts their default 30 s timeout while they wait for the connection, so one queued behind a long statement could still cancel it. They now run through_queued.StatementQueue(core/database/statement_queue.dart) replaces the two copies of the queue in the PostgreSQL and MySQL wrappers. A statement that waits longer thanwaitLimit(2 min) fails withStatementWaitTimeoutExceptionand never runs; the statement it waited for is not touched.Query timed out after 30 sfor a statement that ran too long andWaited 120 s for the connection: another statement is still running on it.for one that never got the session. The error mapper (and through it MCP) maps the wait to its own message and hint. A server cancel without a duration keeps its reason (Query timed out: canceling statement due to user request).Acceptance tests (
test/core/database/statement_queue_test.dart):TimeoutExceptioncloses only its own session;Not in this PR: server-side
statement_timeout/max_execution_timefor the editor and browse sessions (MCP already has its own since #1217), and SQLite still closes its session on a timeout.Closes #1216
Test plan