The idea of 'reusing' in my understanding should be implemented as the following. The semisync mode slave acks on master event receive. The acks are handled by a special master server thread. The ack consists of file:pos and the slave id known too. So SHOW-SLAVE-HOSTS handler should be able to see those data. We'd like to add up the last acked GTID as well to the S-S-H reporting.

anel: What is meant in The semisync can optionally be switched to a "dummy" mode, where the master will no longer wait for slaves ? Semisync always is able to temporarily turning OFF, on master. And then master acts as if the formerly semisync slave is normal.

Thank you for your review

I'm the author of the patchset (https://github.com/MariaDB/server/pull/1427), sadly I have not seen the notification on jira

I'll update soon the code to show GTID as well

About the dummy mode:
Today, when a slave vanishes, the master have to wait rpl_semi_sync_master_timeout msec, during which all CRUD queries are blocked
When that timeout is over, the semi-sync is turned off and operation can continue
If the timeout is too low, the replication will die unnecessarily
If the timeout is too high, the death of a slave will have a large impact on the master

So, I introduced a dummy semi-sync mode, where the master never actually waits for a slave. In that mode, the master never waits for a slave

The GTID is now shown as well:
```
MariaDB [(none)]> show slave hosts;
--------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------

---------------------------------------------------------------------------------
```

All the test are passing
I dropped the "dummy" mode, I'll make another PR later

Thanks

To how to specify the new "dummy" mode, it was suggested (by danblack) on Github, to consider to add up 'NEVER' value to @@global.rpl_semi_sync_master_wait_point.

NONE actually reads better (as it answers to the point "question" in the variable name).

Yes that was the question, what actually sounds better. Glad you've decided.

anel: Salute! Maybe reassigning it back to you makes sense, as we (engineering/replication) don't seem to be able to implement it any time soon. Hopefully by 10.6 GA-ing the idea contributor will come up with the patch fulfilling the requirements.

Salute Elkin, ok, danblack and I will proceed further with this PR.

Setting myself to review the existing patch

I'm assigning to myself to finish this MDEV based on PR review.

Hi bnestere , Elkin, should we use this MDEV (or another) to allow show replica hosts show everything in 1 screen, like how long in time or packets are replicas delayed and if possible other things, to allow users extended view expressing the necessary informations about the state of transactions ?

anel, to whether to use this MDEV to cover up yet more slave state details (if I got the question correctly) I'd vote to do that under another ticket.
Clearly there's a lot to cover on the design level including which side (primary or replica) is responsible for displaying what, and if it's the replica
we'd also need to consider performance_schema as placeholder/interface as a candidate (not least 'cos it provides selectivity by fields).

Review done via Slack

> Review done via Slack

Please don't use non-public channels for review, it makes it impossible for other to follow
Use preferably the developers@ mailing list for reviews, look at Sergei Golubchik's excellent reviews there for inspiration. Or use a channel on Zulip if you need an interactive review sessions.

- Kristian.

Hi Kristian,
the most of the review is done on the PR itself.
Only thing what is left regarding the PR is that Brandon explained to me is how to use rr to debug timeouts for sync_with_master, at the end of the test, since there was single MSAN worker that failed (no log available now). I'm currently trying to repeat locally and understand why happens and fix, still in learning phase.

Thanks anel for the explanation

And knielsen, to the general case, thanks for a great suggestion to use Zulip for interactive sessions! i had indeed used Slack (somewhat reluctantly) for them before.