-
Nuno Carvalho authored
On the previous interface between Group Replication plugin and Performance Tables there was memory allocation which was being passed to server side. This memory allocation should be avoided, also it can cause problems when it is released from a different entity that allocated it. To avoid that issues, now the interface uses callbacks that are invoked by plugin to send information to Performance Schema tables, or other callers. The callback implementations are the ones that are responsible to allocate new memory, if needed. We also changed the definition of performance_schema.replication_group_members table member_state column to be a arbitrary string, being now the plugin the full responsible of its values. The values continue to be: ONLINE, OFFLINE and RECOVERING.
Nuno Carvalho authoredOn the previous interface between Group Replication plugin and Performance Tables there was memory allocation which was being passed to server side. This memory allocation should be avoided, also it can cause problems when it is released from a different entity that allocated it. To avoid that issues, now the interface uses callbacks that are invoked by plugin to send information to Performance Schema tables, or other callers. The callback implementations are the ones that are responsible to allocate new memory, if needed. We also changed the definition of performance_schema.replication_group_members table member_state column to be a arbitrary string, being now the plugin the full responsible of its values. The values continue to be: ONLINE, OFFLINE and RECOVERING.
Loading