On Wed, May 12, 2021 at 02:12:44PM -0300, Joao Morais wrote: > > It's not a matter of first or second access. It's that the function > > you used initially resulted in always allocating an entry for the > > variable's name, causing some huge memory usage for those who were > > using them like maps and performing random lookups there. In order > > to avoid this, Tim added an extra argument saying that we're just > > performing an opportunistic lookup and that the variable must not > > be created if it does not exist. > > Afaics this is only an option for set_var()? Here is the doc: > > TXN.set_var(TXN, var, value[, ifexist]) > TXN.get_var(TXN, var) > http://www.arpalert.org/src/haproxy-lua-api/2.3/index.html > (link is broken from haproxy site, is the source versioned > somewhere so I can send a patch?) > > So lookups would still create variables, hence the "in the second run it > works" - my second script (which reads) create the entry and my first script > (which writes with ifexists true) can find it and update in the second run > and beyond.
That looks really odd, but you're probably right :-( I'll need to have a look at the code to check. Maybe get_var() also needs that argument, or maybe there is something to check if a variable exists, I don't know. But I don't like the way all of this works in general. I think the creation of a variable on a lookup only results from an internal API limitation that was quickly worked around when variables were exposed to Lua, and that it's not too late to fix it. Willy
