Details
Description
SP/PS (Stored Procedures / Prepared Statements) allocates memory till the PS cache of SP will be destroyed. There is no way to see how many memory allocated and if it grows with each execution (first 2 execution can lead to new memory allocation but not more)
Task minimum:
Status variables which count the memory used/allocated for SP/PS by thread and/or for the server.
Other ideas:
- Automatic stop allocation in debugging version after second execution and call exception on attempt.
- Information schema by threads and SP/PS with information about allocated and used memory
Information can be collected in MEM_ROOTs of SP/PS. Storing info about status of mem_root before execution then checking after new allocated memory can be found.
MEM_ROOT can be changed to have debug mode which make it read only which can be switched on after second execution.
Attachments
Issue Links
- blocks
-
MDEV-30073 Wrong result on 2nd execution of PS for query with NOT EXISTS
-
- Stalled
-
- includes
-
MDEV-32466 Potential memory leak on execuing of create view statement
-
- Closed
-
-
MDEV-32517 Memory leak on running query in PS mode with condition that has 'ANY/SOME (subquery)' clause and any kind of the following comparisons '>', '>=', '<', '<=' '
-
- Closed
-
-
MDEV-32733 Two JSON related tests running in PS mode fail on server built with -DWITH_PROTECT_STATEMENT_MEMROOT=YES
-
- Closed
-
- is blocked by
-
MDEV-32369 Memory leak when executing PS for query with IN subquery
-
- Closed
-
- relates to
-
MDEV-30889 Memory leak issues with MariaDB 10.6.12 and OOM Crashes
-
- Stalled
-
-
MDEV-32223 Memory leak showed in MDEV-6146 test suite
-
- Closed
-
-
MDEV-31127 Possible memory leak on running insert in PS mode against a table with a trigger that fires creation of a new partiton
-
- Open
-