By the way, since we're talking about it, I think that actually it's not
logs that we're sending to stderr, it's Lua's alert messages that we're
sending both to stderr and logs.

Well I am no expert in what qualifies as "logs" vs "alerts", but the messages sent from (for example) txn:Info() are included in this logic (which is why I cared in the first place).

If that is an alert, then it's fine, but I would not have expected it.

So maybe it would be more convenient with these two choices:

      tune.lua.alerts-log { on | off }
      tune.lua.alerts-stderr { on | off }

Or with this single one:

      tune.lua.alerts { off | stderr | log | both }

But please keep in mind the default that would change between 2.8 and 2.9
and that would need to be placed at the right location. The last one makes
it less easy in this regard.

I feel like the 2-different-flags approach is a little bit better here, so I'll go with that. Since it also gives the option if ever needed to relatively cleanly extend things later. For example:
- tune.lua.log { off | on [log $logger] [log-format $logfmt] }
- tune.lua.log-stderr { off | on | [min-level $level] }

Not that I necessarily plan either, but the first one would be pretty neat, potentially.

Do what's easier for you. Really. Make sure the final version contains
a patch and a commit message that apply easily (either all inline or
attached, as you see fit). The only thing to avoid is to send multiple
series for review before getting feedback, that's extremely confusing,
but fortunately this almost never happens here.

Ok. Probably will reply to first message of this thread with 2 diff files (one for 2.8 and one for 2.9 to account for default config difference) then.

Tristan


Reply via email to