Bug #7657
closed
My queries show multiple lines for one query
Added by Pavel Kácha 12 months ago.
Updated about 2 months ago.
Category:
Development - Core
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.
- Status changed from New to In Progress
- Assignee set to Rajmund Hruška
- 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.
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 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
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?
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 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
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?
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.
- 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)
- Status changed from Resolved to In Review
- Status changed from In Review to Closed
- 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.
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.
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.
- Status changed from In Progress to In Review
Just nitpicking: shouldn't "You can come back to your query" rather say "You can return to your query"?
- Related to Bug #7710: API requests return 500 when their SQL query is cancelled added
- Status changed from In Review to Closed
Also available in: Atom
PDF