Bug#31177: Server variables can't be set to their current values
Bounds-checks and blocksize corrections were applied to user-input, but constants in the server were trusted implicitly. If these values did not actually meet the requirements, the user could not set change a variable, then set it back to the (wonky) factory default or maximum by explicitly specifying it (SET <var>=<value> vs SET <var>=DEFAULT). Now checks also apply to the server's presets. Wonky values and maxima get corrected at startup. Consequently all non-offsetted values the user sees are valid, and users can set the variable to that exact value if they so desire. mysql-test/r/read_buffer_size_basic.result: test sets out of bounds value; we now throw a warning for this. This is a side-effect: before, the maximum was higher than the value we set here. The value was corrected to block-size, the maximum was not, hence the value was smaller than the maximum in this particular case. Now that we align the maxima at startup, the value in SET is larger than the (corrected) maximum, and we see a warning in this particular case. "This means we're doing it right." mysql-test/r/read_rnd_buffer_size_basic.result: test sets out of bounds value; we now throw a warning for this. This is a side-effect: before, the maximum was higher than the value we set here. The value was corrected to block-size, the maximum was not, hence the value was smaller than the maximum in this particular case. Now that we align the maxima at startup, the value in SET is larger than the (corrected) maximum, and we see a warning in this particular case. "This means we're doing it right." mysys/my_getopt.c: Do bounds-checking at start-up time so we'll catch and correct wonky default values and upper limits. sql/mysqld.cc: If 0 is a legal value per the docs, not to mention the default, we shouldn't give 1 as the lower limit. storage/innobase/handler/ha_innodb.cc: We are setting upper bounds here. ~0L gives -1. That is NOT what we want!
Showing
Please register or sign in to comment