Server ignores asynchronous (monitoring or cancellation) requests while preparing a query with lot of windowed functions [CORE4292] #4615
Comments
Modified by: @pavel-zotovAttachment: prepare_too_long_and_hangs_monitoring.zip [ 12390 ] |
Modified by: @dyemanovsummary: MON$-tables are unavaliable when optimizer prepares to execute query with lot of windowed functions => Server ignores asynchronous (monitoring or cancellation) requests while preparing a query with lot of windowed functions |
Modified by: @dyemanovRegression: 3.0 Alpha 1 [ 10331 ] |
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovFix Version: 3.0 RC 1 [ 10584 ] |
Modified by: @asfernandesassignee: Dmitry Yemanov [ dimitr ] => Adriano dos Santos Fernandes [ asfernandes ] status: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] |
|
Commented by: @pavel-zotov Still can`t understand: why attachment that preparing complex query too long and than is killed by another, does not quits from ISQL. Session #1 SQL> Session #2 isql /3333:e30 -q SQL> in prepare_too_long_and_hangs_monitoring.sql ; -- this file you can see in attached .zip Session #1 SQL> commit; select * from mon$attachments where mon$remote_address is not null and mon$attachment_id<>current_connection; MON$ATTACHMENT_ID 9 SQL> commit; delete from mon$attachments; Session #2 PS. Checked on SuperServer. ISQL Version: WI-V3.0.0.32067 Firebird 3.0 Release Candidate 1 |
|
Commented by: @dyemanov Asynchronous cancellation usually don't affect queries being prepared. One particular case (for this ticket) was improved, but no general solution exists yet. |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: Done successfully Test Details: Checked on WI-V3.0.0.32081, SS / SC / CS (32 bit). Result: all fine. |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: @pavel-zotov
Attachments:
prepare_too_long_and_hangs_monitoring.zip
Consider two complex queries - see attach.
Script "prepare_too_long_and_hangs_monitoring.sql" contains a lot of calls to windowed functions and script "also_complex_but_NOT_trouble_in_preparing.sql" has no such calls but contains lot of scalar subqueries (in places where windowed functions were in first one).
The following scenario illustrates what there will be if we try to get execution plan of both queries.
session #1
C:\1Install\fb30>isql localhost/3330:empty30 -n
Database: localhost/3330:empty30
SQL>
session #2
C:\1Install\fb30>isql localhost/3330:empty30 -n
Database: localhost/3330:empty30
SQL> in prepare_too_long_and_hangs_monitoring.sql;
-- hangs (preparing takes about five minutes on my Linux server)
session #1
SQL> set list on;
SQL> commit; select * from mon$attachments where mon$attachment_id<>current_connection
CON> and mon$remote_protocol > is not null;
-- ALSO HANGS untill execution plan will appear in session #2!
So, we can not querying MON$ATTACHMENTS during five minutes. And any other MON$-tables too.
PS. Script "also_complex_but_NOT_trouble_in_preparing.sql" does not leads to such trouble though it also too comples and also have lot of "calls" inside itself.
Commits: 68e2043 FirebirdSQL/fbt-repository@9317da9
====== Test Details ======
Checked on WI-V3.0.0.32081, SS / SC / CS (32 bit). Result: all fine.
The text was updated successfully, but these errors were encountered: