You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When one performs an INSERT ... SELECT statement with a long-running SELECT query, and then disconnects the session, adapter does not cancel the in-progress peek.
CREATETABLEt1 (f1 INTEGER);
INSERT INTO t1 WITH MUTUALLY RECURSIVE flip(x INTEGER) AS (VALUES(1) EXCEPT ALL SELECT*FROM flip) SELECT*FROM flip;
Note that this example uses WMR, which needs to be enable through --unsafe-mode or the feature flag, to produce a divergent query that will never return. Any other slow query works too.
Forcefully disconnect the session from another terminal, e.g.:
$ killall psql
Observe that adapter is not immediately cancelling the in-progress peek with the compute controller. The cancellation only happens when the statement timeout occurs. This behavior is different than for regular SELECT queries, which are cancelled immediately on session disconnect.
Note that the bug might be difficult to observe, depending on your test query. For example, the above divergent WMR query will never stop running regardless of whether the peek was cancelled or not (#16800). I suggest you instrument the code to print when the compute controller receives a CancelPeeks command.
Relevant log output
No response
The text was updated successfully, but these errors were encountered:
What version of Materialize are you using?
main
How did you install Materialize?
Built from source
What is the issue?
When one performs an
INSERT ... SELECT
statement with a long-runningSELECT
query, and then disconnects the session, adapter does not cancel the in-progress peek.To reproduce (courtesy of @philip-stoev):
Start a long-running
INSERT ... SELECT
, e.g.:Note that this example uses WMR, which needs to be enable through
--unsafe-mode
or the feature flag, to produce a divergent query that will never return. Any other slow query works too.Forcefully disconnect the session from another terminal, e.g.:
Observe that adapter is not immediately cancelling the in-progress peek with the compute controller. The cancellation only happens when the statement timeout occurs. This behavior is different than for regular
SELECT
queries, which are cancelled immediately on session disconnect.Note that the bug might be difficult to observe, depending on your test query. For example, the above divergent WMR query will never stop running regardless of whether the peek was cancelled or not (#16800). I suggest you instrument the code to print when the compute controller receives a
CancelPeeks
command.Relevant log output
No response
The text was updated successfully, but these errors were encountered: