Excessive stack memory usage due to WSREP_LOG

Several tests fail on 10.4 kvm-asan due to stack overrun:

Failing test(s): sys_vars.max_sp_recursion_depth_func main.signal_demo3 compat/oracle.sp-package rpl.rpl_row_sp011 main.sp

The main contributor to this stack overrun is mysql_execute_command().

Rebuilding with cmake -DWITH_WSREP=OFF shrunk the size of the mysql_execute_command() stack frame in the ASAN debug build from 29312 to 17568 bytes. A quick and dirty workaround made the tests pass:

diff --git a/sql/wsrep_mysqld.h b/sql/wsrep_mysqld.h

--- a/sql/wsrep_mysqld.h

+++ b/sql/wsrep_mysqld.h

@@ -245,7 +245,7 @@ extern wsrep_seqno_t wsrep_locked_seqno;

 // prefix all messages with "WSREP"

 #define WSREP_LOG(fun, ...)                                       \

     do {                                                          \

-        char msg[1024]= {'\0'};                                  \

+        char msg[1]= {'\0'};                                  \

         snprintf(msg, sizeof(msg) - 1, ## __VA_ARGS__);           \

         fun("WSREP: %s", msg);                                    \

     } while(0)

It turns out that this bug had been fixed in MariaDB 10.3.1 but the fix was destroyed in the Galera 4 merge (MDEV-16405).

This bug should affect all builds, especially affecting the execution of complex stored procedures, which involves recursive calls to mysql_execute_command(). The WSREP_DEBUG macro invocations will expand to WSREP_LOG also in non-debug builds, and obviously, the stack memory will be allocated even with the default settings (WSREP or Galera are disabled).