Bug #7657
closedMy queries show multiple lines for one query
50%
Description
My queries probably show all the processes, which are spawned by PostgreSQL for one query. As PQ now uses multiprocessing quite extensively, this results into puzzling situation (for user), where he does not now, which query to kill (or all?) in case he reaches the limit. We should probably group multiple processes for one query into one record, and allow to kill the query as a whole.
Related issues
Updated by Rajmund Hruška 11 months ago
- Status changed from New to In Progress
- Assignee set to Rajmund Hruška
Updated by Rajmund Hruška 11 months ago
- To be discussed changed from No to Yes
So, I added a filter which discards queries where backend_type='parallel worker' and I edited the query to kill process where backend_type='client backend'. This cancels the process, but then another process is created with the same query. After killing this next one, the query is over and the original page, where query was executed results in 500 Internal server error.
So, those two issues need to be solved now.
Updated by Pavel Kácha 11 months ago
Rajmund Hruška wrote in #note-2:
So, I added a filter which discards queries where
backend_type='parallel worker'and I edited the query to kill process wherebackend_type='client backend'. This cancels the process, but then another process is created with the same query. After killing this next one, the query is over
A quick look regarding this - maybe lib/mentat/services/eventstorage.py(981)? There's (arguably ugly) hardcoded for _ in range(2) .
Isn't it deductible from the psycopg2 exception that query has been ended forcibly to take specialised care?
Updated by Rajmund Hruška 11 months ago
Pavel Kácha wrote in #note-3:
Rajmund Hruška wrote in #note-2:
So, I added a filter which discards queries where
backend_type='parallel worker'and I edited the query to kill process wherebackend_type='client backend'. This cancels the process, but then another process is created with the same query. After killing this next one, the query is overA quick look regarding this - maybe lib/mentat/services/eventstorage.py(981)? There's (arguably ugly) hardcoded
for _ in range(2).Isn't it deductible from the psycopg2 exception that query has been ended forcibly to take specialised care?
Yes, you are correct in both points. The exception which is not handled is psycopg2.errors.QueryCanceled and since there is no catch block, it results in mentat.services.eventstorage.EventStorageException following by 500 error.
Updated by Rajmund Hruška 11 months ago
- Status changed from In Progress to Resolved
- Target version changed from Backlog to 2.11
- % Done changed from 0 to 100
- To be discussed deleted (
Yes)
Updated by Rajmund Hruška 11 months ago
- Status changed from Resolved to In Review
Updated by Rajmund Hruška 9 months ago
- Status changed from Closed to In Progress
- Target version changed from 2.11 to 2.12
- % Done changed from 100 to 50
Looks like there is still an issue. It seems like the parallel workers are still counted in the search query quota.
Updated by Rajmund Hruška 8 months ago
Rajmund Hruška wrote in #note-8:
Looks like there is still an issue. It seems like the parallel workers are still counted in the search query quota.
For the moment, I have increased the search query quota to 70 from 7 on mentat-hub.
Updated by Pavel Kácha 4 months ago
Rajmund Hruska wrote in #note-9:
Rajmund Hruška wrote in #note-8:
Looks like there is still an issue. It seems like the parallel workers are still counted in the search query quota.
For the moment, I have increased the search query quota to 70 from 7 on
mentat-hub.
Confirmed on mentat-alt. I get 400 (event limit 7) on event search while simultaneously running just one timeline query.
Updated by Rajmund Hruška 3 months ago
- Status changed from In Progress to In Review
Updated by Pavel Kácha 3 months ago
Just nitpicking: shouldn't "You can come back to your query" rather say "You can return to your query"?
Updated by Jakub Maloštik about 2 months ago
- Related to Bug #7710: API requests return 500 when their SQL query is cancelled added
Updated by Rajmund Hruška about 1 month ago
- Status changed from In Review to Closed