-
Notifications
You must be signed in to change notification settings - Fork 24.4k
Support function flags in script EVAL via shebang header #10126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support function flags in script EVAL via shebang header #10126
Conversation
…ptPrepareForRun` can know it's in EVAL mode too.
Co-authored-by: sundb <sundbcn@gmail.com>
|
It's a pretty cool trick to use the shebang, but one would expect that it's also usable in a Unix system. A shebang starting with |
|
@zuiderkwast the thing is that we want to be able to parse the flags and store them per script without executing it. with your suggestion, we either execute that line to get the flags, or alternatively just attempt to parse it, but it'll be odd if it looks like Lua code where in fact we just parse it. i'd rather use simple string splitting to get the flags (and maybe other args in the future. |
The fact that it's masquerading as something which it's isn't is potentially confusing. How about allowing them within any kind of comment, with an additional "redis flags" tag on e.g. one of the two first lines of the script, so depending on the language, either of the below (idea, not exact syntax): |
oranagra
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good. obviously missing tests 8-)
Co-authored-by: Oran Agra <oran@redislabs.com>
…s into script-shebang-flags
Including backwards compatibility mode for no shebang and tests.
Co-authored-by: Oran Agra <oran@redislabs.com>
|
@redis/core-team please approve. |
|
For the record, this was conceptually approved in a core-team meeting. |
|
@yoav-steinberg i just realized that this broke the defragger. |
In redis#10126 the global `lua_script` dict became a dict to a custom `luaScript` struct with an internal `robj` in it instead of a generic `sds` -> `robj` dict. This means we need custom code to defrag it and since scripts should never really cause much fragmentation it makes more sense to simply remove the defrag code for scripts.
This reverts commit e05c979.
Remove scripts defragger since it was broken since #10126 (released in 7.0 RC1). would crash the server if defragger starts in a server that contains eval scripts. In #10126 the global `lua_script` dict became a dict to a custom `luaScript` struct with an internal `robj` in it instead of a generic `sds` -> `robj` dict. This means we need custom code to defrag it and since scripts should never really cause much fragmentation it makes more sense to simply remove the defrag code for scripts.
In #10025 we added a mechanism for flagging certain properties for Redis Functions. This lead us to think we'd like to "port" this mechanism to Redis Scripts (
EVAL) as well.One good reason for this, other than the added functionality is because it addresses the poor behavior we currently have in
EVALin case the script performs a (non DENY_OOM) write operation during OOM state. See #8478 (And a previous attempt to handle it via #10093) for details. Note that in Redis Functions all write operations (including DEL) will return an error during OOM state unless the function is flagged asallow-oomin which case no OOM checking is performed at all.This PR:
EVAL(andSCRIPT LOAD) script flags as defined in Redis Functions Flags #10025.EVAL[SHA]/_ROto be flagged asSTALEcommands. This makes it possible to flag individual scripts asallow-staleor not flag them as such. In backwards compatibility mode these commands will return theMASTERDOWNerror as before.SCRIPT LOADto be flagged as aSTALEcommand. This is mainly to make it logically compatible with the change toEVALin the previous point. It enables loading a script on a stale server which is technically okay it doesn't relate directly to the server's dataset. Running the script does, but that won't work unless the script is explicitly marked asallow-stale.Even though not strictly required this should replace #10093. We also suggest closing #8478: using the shebang will cause the script to change its default behavior so it'll deny any writes during OOM state.
Usage example:
Note that even though the LUA syntax doesn't support hash tag comments
.luafiles do support a shebang tag on the top so they can be executed on Unix systems like any shell script. LUA'sluaL_loadfilehandles this as part of the LUA library. In the case ofluaL_loadbuffer, which is what Redis uses, I needed to fix the input script in case of a shebang manually. I did this the same wayluaL_loadfiledoes, by replacing the first line with a single line feed character.