[MXS-301] Do not limit setting session parameters in session_cmd_history (Optimize session history) Created: 2015-08-06  Updated: 2017-12-01  Resolved: 2017-03-20

Status: Closed
Project: MariaDB MaxScale
Component/s: N/A
Affects Version/s: None
Fix Version/s: N/A

Type: New Feature Priority: Minor
Reporter: Joffrey MICHAIE (Inactive) Assignee: Unassigned
Resolution: Won't Do Votes: 1
Labels: None

Issue Links:
Relates
relates to MXS-387 Optimize session history. Closed

 Description   

Hi,

due to recently found memory leaks, a new parameter to limit (or disable) the session variables history has been set.

I think it could be easily improved, by distinguishing session parameters and session variables.
Most of the applications do set session parameters (such as join_buffer_size by ex)
For such parameters, if a user sets it many times (example...) :
set session join_buffer_size=32*1024*1024;
set session join_buffer_size=64*1024*1024;
set session join_buffer_size=32*1024*1024;
set session join_buffer_size=64*1024*1024;
We don't need to store all previous values, but only the last one.

MySQL/Maria allows you to set maybe up to 400 different session parameters. It could be easy to store them in an array, and keep them forever, without leaking too much memory.

On the contrary, I agree that setting user defined variables, such as:
SET @myvarA = NOW();
SET @myvarB = NOW();
SET @myvarC = NOW();
could and should be limited in terms of size.

I don't know what other session things that are kept in this "session cmd history", but they could go to any of the mentionned groups above.

What do you think?
Thanks,
Joffrey



 Comments   
Comment by Dipti Joshi (Inactive) [ 2015-08-06 ]

markus makela Please add estimate for this task.

Thanks,
Dipti

Comment by Dipti Joshi (Inactive) [ 2015-08-06 ]

Thanks markus makela for estimate ! So minor for priority not work - so keeping it for future release

Dipti

Comment by Johan Wikman [ 2016-03-01 ]

Removed fix-version as it won't be implemented for 1.4.

Generated at Thu Feb 08 03:58:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.