Closed
Description
Enhancement
To avoid the bug in concurrent executing statements, TiDB fetches all the results and stored them in the memory. The following FETCH
command only reads data from memory. It's especially hard for TiDB to support a real "CursorFetch", as the execution model of TiDB assumes that the access to session struct is exclusive, which is not true for "CursorFetch".
This behavior will cause OOM, when the result set is big or there are many cursor fetch statement. It's even more unexpected as the user may only need the first several rows. We could have some ways to relief this problem:
- Trace the memory through setting a suitable chunk allocator. However, the connection allocator will reset after command execution, so we need a new allocator across different statements.
- Spill result to disk if needed.
Activity