Hi Marko and Kristian

>> I also had the idea to use fibers/coroutines as is mentined in the MDEV

>> description, but if that can be avoided, so much the better.

>I too like https://quoteinvestigator.com/2011/05/13/einstein-simple/

>or the KISS principle.

About MDEV-24341

That was not implemented as fibers or coroutines after all, but still do_command() is a restartable function, that just uses goto to jump to the place where it left off last time. Luckily, there is only one restartability point – at the end of the query, prior to reporting OK to client, where we would otherwise need to wait for innodb group commit lead to make the changes persistent

“coroutine-like” is only active if threadpool is used –do_command completes only partially, and frees the worker thread, so that it can accept requests from somebody else.  The group commit lead thread takes care of resuming unfinished do_commands, after redo log is written/flushed.

With thread-per-connection, coroutine-like logic above makes no sense. But still, wait for persistent redo is delayed until the last possible moment , when the server writes to network, to report OK to the client . This delay allows to either decrease wait time, or avoid it entirely, depending on how fast the group commit lead finishes its work.

However  if binlog is used, none of the above would happen. Lacking binlog  knowledge, I took conservative approach. Therefore,  with  binlog on, all waits for persistent Innodb redo  are “synchronous”, i.e they happen inside Innodb’s log_write_up_to() function.

Wlad

_______________________________________________

Mailing list: https://launchpad.net/~maria-developers

Post to     : maria-developers@lists.launchpad.net

Unsubscribe : https://launchpad.net/~maria-developers

More help   : https://help.launchpad.net/ListHelp