[Maria-discuss] Innodb_buffer_pool_read_requests is zero
Just upgraded from 10.6.12 to 10.6.13 on a Debian Bullseye system, and seeing this oddity. Innodb_buffer_pool_read_requests is zero, and seems to remain at zero no matter what I do (I even tried selecting all the data from a small table several times in a row with no change). It's been running a couple hours now; I've restarted it a couple times. I have 10.6.13 on a few other platforms as well (including Buster), and I'm not seeing the same issue on them. What would cause this? I have no other Bullseye systems running 10.6.13 yet, and the same system has been running 10.6.12 for over a week now without showing this issue. The system _seems_ to be running fine, it's a replica system that is being fed actively from the master (data comes in to it very regularly). MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_%'; +-----------------------------------------+--------------------------------------------------+ | Variable_name | Value | +-----------------------------------------+--------------------------------------------------+ | Innodb_buffer_pool_dump_status | | | Innodb_buffer_pool_load_status | Buffer pool(s) load completed at 230511 23:21:26 | | Innodb_buffer_pool_resize_status | | | Innodb_buffer_pool_load_incomplete | OFF | | Innodb_buffer_pool_pages_data | 609103 | | Innodb_buffer_pool_bytes_data | 9979543552 | | Innodb_buffer_pool_pages_dirty | 19465 | | Innodb_buffer_pool_bytes_dirty | 318914560 | | Innodb_buffer_pool_pages_flushed | 0 | | Innodb_buffer_pool_pages_free | 299441 | | Innodb_buffer_pool_pages_made_not_young | 0 | | Innodb_buffer_pool_pages_made_young | 107 | | Innodb_buffer_pool_pages_misc | 0 | | Innodb_buffer_pool_pages_old | 224824 | | Innodb_buffer_pool_pages_total | 908544 | | Innodb_buffer_pool_pages_lru_flushed | 0 | | Innodb_buffer_pool_pages_lru_freed | 0 | | Innodb_buffer_pool_pages_split | 726 | | Innodb_buffer_pool_read_ahead_rnd | 0 | | Innodb_buffer_pool_read_ahead | 3 | | Innodb_buffer_pool_read_ahead_evicted | 0 | | Innodb_buffer_pool_read_requests | 0 | | Innodb_buffer_pool_reads | 604346 | | Innodb_buffer_pool_wait_free | 0 | | Innodb_buffer_pool_write_requests | 3639341 | +-----------------------------------------+--------------------------------------------------+ 25 rows in set (0.000 sec) MariaDB [(none)]> SHOW VARIABLES LIKE 'innodb_buffer_pool%'; +-------------------------------------+----------------+ | Variable_name | Value | +-------------------------------------+----------------+ | innodb_buffer_pool_chunk_size | 134217728 | | innodb_buffer_pool_dump_at_shutdown | ON | | innodb_buffer_pool_dump_now | OFF | | innodb_buffer_pool_dump_pct | 80 | | innodb_buffer_pool_filename | ib_buffer_pool | | innodb_buffer_pool_load_abort | OFF | | innodb_buffer_pool_load_at_startup | ON | | innodb_buffer_pool_load_now | OFF | | innodb_buffer_pool_size | 15032385536 | +-------------------------------------+----------------+ 9 rows in set (0.000 sec)
I've also noticed that my transaction history length is always zero; that's true on all my 10.6.13 instances (not just Bullseye). Is that information no longer stored here? SELECT `count` FROM information_schema.INNODB_METRICS WHERE name = 'trx_rseg_history_len'; On 5/11/2023 11:55 PM, mariadb@biblestuph.com wrote:
Just upgraded from 10.6.12 to 10.6.13 on a Debian Bullseye system, and seeing this oddity. Innodb_buffer_pool_read_requests is zero, and seems to remain at zero no matter what I do (I even tried selecting all the data from a small table several times in a row with no change). It's been running a couple hours now; I've restarted it a couple times. I have 10.6.13 on a few other platforms as well (including Buster), and I'm not seeing the same issue on them. What would cause this? I have no other Bullseye systems running 10.6.13 yet, and the same system has been running 10.6.12 for over a week now without showing this issue.
The system _seems_ to be running fine, it's a replica system that is being fed actively from the master (data comes in to it very regularly).
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_%'; +-----------------------------------------+--------------------------------------------------+ | Variable_name | Value | +-----------------------------------------+--------------------------------------------------+ | Innodb_buffer_pool_dump_status | | | Innodb_buffer_pool_load_status | Buffer pool(s) load completed at 230511 23:21:26 | | Innodb_buffer_pool_resize_status | | | Innodb_buffer_pool_load_incomplete | OFF | | Innodb_buffer_pool_pages_data | 609103 | | Innodb_buffer_pool_bytes_data | 9979543552 | | Innodb_buffer_pool_pages_dirty | 19465 | | Innodb_buffer_pool_bytes_dirty | 318914560 | | Innodb_buffer_pool_pages_flushed | 0 | | Innodb_buffer_pool_pages_free | 299441 | | Innodb_buffer_pool_pages_made_not_young | 0 | | Innodb_buffer_pool_pages_made_young | 107 | | Innodb_buffer_pool_pages_misc | 0 | | Innodb_buffer_pool_pages_old | 224824 | | Innodb_buffer_pool_pages_total | 908544 | | Innodb_buffer_pool_pages_lru_flushed | 0 | | Innodb_buffer_pool_pages_lru_freed | 0 | | Innodb_buffer_pool_pages_split | 726 | | Innodb_buffer_pool_read_ahead_rnd | 0 | | Innodb_buffer_pool_read_ahead | 3 | | Innodb_buffer_pool_read_ahead_evicted | 0 | | Innodb_buffer_pool_read_requests | 0 | | Innodb_buffer_pool_reads | 604346 | | Innodb_buffer_pool_wait_free | 0 | | Innodb_buffer_pool_write_requests | 3639341 | +-----------------------------------------+--------------------------------------------------+ 25 rows in set (0.000 sec)
MariaDB [(none)]> SHOW VARIABLES LIKE 'innodb_buffer_pool%'; +-------------------------------------+----------------+ | Variable_name | Value | +-------------------------------------+----------------+ | innodb_buffer_pool_chunk_size | 134217728 | | innodb_buffer_pool_dump_at_shutdown | ON | | innodb_buffer_pool_dump_now | OFF | | innodb_buffer_pool_dump_pct | 80 | | innodb_buffer_pool_filename | ib_buffer_pool | | innodb_buffer_pool_load_abort | OFF | | innodb_buffer_pool_load_at_startup | ON | | innodb_buffer_pool_load_now | OFF | | innodb_buffer_pool_size | 15032385536 | +-------------------------------------+----------------+ 9 rows in set (0.000 sec)
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Figured out trx_rseg_history_len; it's just disabled by default now. But still stumped on Innodb_buffer_pool_read_requests. On 5/12/2023 2:40 AM, mariadb@biblestuph.com wrote:
I've also noticed that my transaction history length is always zero; that's true on all my 10.6.13 instances (not just Bullseye). Is that information no longer stored here?
SELECT `count` FROM information_schema.INNODB_METRICS WHERE name = 'trx_rseg_history_len';
On 5/11/2023 11:55 PM, mariadb@biblestuph.com wrote:
Just upgraded from 10.6.12 to 10.6.13 on a Debian Bullseye system, and seeing this oddity. Innodb_buffer_pool_read_requests is zero, and seems to remain at zero no matter what I do (I even tried selecting all the data from a small table several times in a row with no change). It's been running a couple hours now; I've restarted it a couple times. I have 10.6.13 on a few other platforms as well (including Buster), and I'm not seeing the same issue on them. What would cause this? I have no other Bullseye systems running 10.6.13 yet, and the same system has been running 10.6.12 for over a week now without showing this issue.
The system _seems_ to be running fine, it's a replica system that is being fed actively from the master (data comes in to it very regularly).
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_%'; +-----------------------------------------+--------------------------------------------------+ | Variable_name | Value | +-----------------------------------------+--------------------------------------------------+ | Innodb_buffer_pool_dump_status | | | Innodb_buffer_pool_load_status | Buffer pool(s) load completed at 230511 23:21:26 | | Innodb_buffer_pool_resize_status | | | Innodb_buffer_pool_load_incomplete | OFF | | Innodb_buffer_pool_pages_data | 609103 | | Innodb_buffer_pool_bytes_data | 9979543552 | | Innodb_buffer_pool_pages_dirty | 19465 | | Innodb_buffer_pool_bytes_dirty | 318914560 | | Innodb_buffer_pool_pages_flushed | 0 | | Innodb_buffer_pool_pages_free | 299441 | | Innodb_buffer_pool_pages_made_not_young | 0 | | Innodb_buffer_pool_pages_made_young | 107 | | Innodb_buffer_pool_pages_misc | 0 | | Innodb_buffer_pool_pages_old | 224824 | | Innodb_buffer_pool_pages_total | 908544 | | Innodb_buffer_pool_pages_lru_flushed | 0 | | Innodb_buffer_pool_pages_lru_freed | 0 | | Innodb_buffer_pool_pages_split | 726 | | Innodb_buffer_pool_read_ahead_rnd | 0 | | Innodb_buffer_pool_read_ahead | 3 | | Innodb_buffer_pool_read_ahead_evicted | 0 | | Innodb_buffer_pool_read_requests | 0 | | Innodb_buffer_pool_reads | 604346 | | Innodb_buffer_pool_wait_free | 0 | | Innodb_buffer_pool_write_requests | 3639341 | +-----------------------------------------+--------------------------------------------------+ 25 rows in set (0.000 sec)
MariaDB [(none)]> SHOW VARIABLES LIKE 'innodb_buffer_pool%'; +-------------------------------------+----------------+ | Variable_name | Value | +-------------------------------------+----------------+ | innodb_buffer_pool_chunk_size | 134217728 | | innodb_buffer_pool_dump_at_shutdown | ON | | innodb_buffer_pool_dump_now | OFF | | innodb_buffer_pool_dump_pct | 80 | | innodb_buffer_pool_filename | ib_buffer_pool | | innodb_buffer_pool_load_abort | OFF | | innodb_buffer_pool_load_at_startup | ON | | innodb_buffer_pool_load_now | OFF | | innodb_buffer_pool_size | 15032385536 | +-------------------------------------+----------------+ 9 rows in set (0.000 sec)
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Hi, The INNODB_METRICS are partly duplicating global status variables. I would actually like to remove them eventually; see https://jira.mariadb.org/browse/MDEV-15706. This interface was designed in MySQL before performance_schema was developed. I do not know if the author considered using status variables. The regressions that you found were not intentional; we should avoid changing interfaces within GA releases such as 10.6. The only intentional change was to remove some "double bookkeeping" and let some INNODB_METRICS counters reflect counters that are already being maintained for other reasons, instead of duplicating them. Some indirection for the counter Innodb_buffer_pool_read_requests was removed in MDEV-26827: the duplicate global variable export_vars.innodb_buffer_pool_read_requests was removed and the status variable should reflect buf_pool.stat.n_page_gets directly. When diagnosing https://jira.mariadb.org/browse/MDEV-29967 I did see that counter being incremented. The statement that I used was: show global status like 'innodb_buffer_pool_read%'; Can you please file a bug with exact steps on how to reproduce this? Marko On Fri, May 12, 2023 at 10:12 AM <mariadb@biblestuph.com> wrote:
Figured out trx_rseg_history_len; it's just disabled by default now. But still stumped on Innodb_buffer_pool_read_requests.
On 5/12/2023 2:40 AM, mariadb@biblestuph.com wrote:
I've also noticed that my transaction history length is always zero; that's true on all my 10.6.13 instances (not just Bullseye). Is that information no longer stored here?
SELECT `count` FROM information_schema.INNODB_METRICS WHERE name = 'trx_rseg_history_len';
On 5/11/2023 11:55 PM, mariadb@biblestuph.com wrote:
Just upgraded from 10.6.12 to 10.6.13 on a Debian Bullseye system, and seeing this oddity. Innodb_buffer_pool_read_requests is zero, and seems to remain at zero no matter what I do (I even tried selecting all the data from a small table several times in a row with no change). It's been running a couple hours now; I've restarted it a couple times. I have 10.6.13 on a few other platforms as well (including Buster), and I'm not seeing the same issue on them. What would cause this? I have no other Bullseye systems running 10.6.13 yet, and the same system has been running 10.6.12 for over a week now without showing this issue.
The system _seems_ to be running fine, it's a replica system that is being fed actively from the master (data comes in to it very regularly).
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_%'; +-----------------------------------------+--------------------------------------------------+ | Variable_name | Value | +-----------------------------------------+--------------------------------------------------+ | Innodb_buffer_pool_dump_status | | | Innodb_buffer_pool_load_status | Buffer pool(s) load completed at 230511 23:21:26 | | Innodb_buffer_pool_resize_status | | | Innodb_buffer_pool_load_incomplete | OFF | | Innodb_buffer_pool_pages_data | 609103 | | Innodb_buffer_pool_bytes_data | 9979543552 | | Innodb_buffer_pool_pages_dirty | 19465 | | Innodb_buffer_pool_bytes_dirty | 318914560 | | Innodb_buffer_pool_pages_flushed | 0 | | Innodb_buffer_pool_pages_free | 299441 | | Innodb_buffer_pool_pages_made_not_young | 0 | | Innodb_buffer_pool_pages_made_young | 107 | | Innodb_buffer_pool_pages_misc | 0 | | Innodb_buffer_pool_pages_old | 224824 | | Innodb_buffer_pool_pages_total | 908544 | | Innodb_buffer_pool_pages_lru_flushed | 0 | | Innodb_buffer_pool_pages_lru_freed | 0 | | Innodb_buffer_pool_pages_split | 726 | | Innodb_buffer_pool_read_ahead_rnd | 0 | | Innodb_buffer_pool_read_ahead | 3 | | Innodb_buffer_pool_read_ahead_evicted | 0 | | Innodb_buffer_pool_read_requests | 0 | | Innodb_buffer_pool_reads | 604346 | | Innodb_buffer_pool_wait_free | 0 | | Innodb_buffer_pool_write_requests | 3639341 | +-----------------------------------------+--------------------------------------------------+ 25 rows in set (0.000 sec)
MariaDB [(none)]> SHOW VARIABLES LIKE 'innodb_buffer_pool%'; +-------------------------------------+----------------+ | Variable_name | Value | +-------------------------------------+----------------+ | innodb_buffer_pool_chunk_size | 134217728 | | innodb_buffer_pool_dump_at_shutdown | ON | | innodb_buffer_pool_dump_now | OFF | | innodb_buffer_pool_dump_pct | 80 | | innodb_buffer_pool_filename | ib_buffer_pool | | innodb_buffer_pool_load_abort | OFF | | innodb_buffer_pool_load_at_startup | ON | | innodb_buffer_pool_load_now | OFF | | innodb_buffer_pool_size | 15032385536 | +-------------------------------------+----------------+ 9 rows in set (0.000 sec)
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
-- Marko Mäkelä, Lead Developer InnoDB MariaDB plc
Thanks for the reply. I've tried to recreate this several times in a virtual environment with Bullseye, but have been unable to. When I upgrade I always save off the data and remove the old apps first (in this case dpkg -P <package>). When I did it this time I had forgotten to restore /var/log/mysql--where I keep all my binary, relay, and error logs--before restarting so I got the "Could not initialize master info structure ..." error. Had to stop it and after restoring the data and doing some tweaks was able to get the slave going again at the right spot. It wasn't until awhile after that that I noticed Innodb_buffer_pool_read_requests wasn't populating. Again, I tried that same process in a virtual machine and Innodb_buffer_pool_read_requests always populates fine, I don't know what I did differently last night. In the meantime, that one machine continues to refuse to populate it, though I do see it populating in INNODB_METRICS: MariaDB [(none)]> select * from information_schema.INNODB_METRICS where name = 'buffer_pool_read_requests' \G *************************** 1. row *************************** NAME: buffer_pool_read_requests SUBSYSTEM: buffer COUNT: 360830807 MAX_COUNT: 360830807 MIN_COUNT: NULL AVG_COUNT: 57936.9 COUNT_RESET: 360830807 MAX_COUNT_RESET: 360830807 MIN_COUNT_RESET: NULL AVG_COUNT_RESET: NULL TIME_ENABLED: 2023-05-12 09:38:37 TIME_DISABLED: NULL TIME_ELAPSED: 6228 TIME_RESET: NULL ENABLED: 1 TYPE: status_counter COMMENT: Number of logical read requests (innodb_buffer_pool_read_requests) 1 row in set (0.000 sec) MariaDB [(none)]> show global status like 'innodb_buffer_pool_read_requests'; +----------------------------------+-------+ | Variable_name | Value | +----------------------------------+-------+ | Innodb_buffer_pool_read_requests | 0 | +----------------------------------+-------+ 1 row in set (0.000 sec) I've tweaked my scripts that need that value to get it from INNODB_METRICS, instead. Other than INNODB_METRICS possibly going away in a future release, are there any long-term negatives that I might encounter with this setup? I.E., any other potential problems I might encounter relating to the Innodb_buffer_pool_read_requests status variable being zero? On 5/12/2023 3:53 AM, Marko Mäkelä wrote:
Hi,
The INNODB_METRICS are partly duplicating global status variables. I would actually like to remove them eventually; see https://jira.mariadb.org/browse/MDEV-15706. This interface was designed in MySQL before performance_schema was developed. I do not know if the author considered using status variables.
The regressions that you found were not intentional; we should avoid changing interfaces within GA releases such as 10.6. The only intentional change was to remove some "double bookkeeping" and let some INNODB_METRICS counters reflect counters that are already being maintained for other reasons, instead of duplicating them.
Some indirection for the counter Innodb_buffer_pool_read_requests was removed in MDEV-26827: the duplicate global variable export_vars.innodb_buffer_pool_read_requests was removed and the status variable should reflect buf_pool.stat.n_page_gets directly. When diagnosing https://jira.mariadb.org/browse/MDEV-29967 I did see that counter being incremented. The statement that I used was:
show global status like 'innodb_buffer_pool_read%';
Can you please file a bug with exact steps on how to reproduce this?
Marko
On Fri, May 12, 2023 at 10:12 AM <mariadb@biblestuph.com> wrote:
Figured out trx_rseg_history_len; it's just disabled by default now. But still stumped on Innodb_buffer_pool_read_requests.
On 5/12/2023 2:40 AM, mariadb@biblestuph.com wrote:
I've also noticed that my transaction history length is always zero; that's true on all my 10.6.13 instances (not just Bullseye). Is that information no longer stored here?
SELECT `count` FROM information_schema.INNODB_METRICS WHERE name = 'trx_rseg_history_len';
On 5/11/2023 11:55 PM, mariadb@biblestuph.com wrote:
Just upgraded from 10.6.12 to 10.6.13 on a Debian Bullseye system, and seeing this oddity. Innodb_buffer_pool_read_requests is zero, and seems to remain at zero no matter what I do (I even tried selecting all the data from a small table several times in a row with no change). It's been running a couple hours now; I've restarted it a couple times. I have 10.6.13 on a few other platforms as well (including Buster), and I'm not seeing the same issue on them. What would cause this? I have no other Bullseye systems running 10.6.13 yet, and the same system has been running 10.6.12 for over a week now without showing this issue.
The system _seems_ to be running fine, it's a replica system that is being fed actively from the master (data comes in to it very regularly).
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_%'; +-----------------------------------------+--------------------------------------------------+ | Variable_name | Value | +-----------------------------------------+--------------------------------------------------+ | Innodb_buffer_pool_dump_status | | | Innodb_buffer_pool_load_status | Buffer pool(s) load completed at 230511 23:21:26 | | Innodb_buffer_pool_resize_status | | | Innodb_buffer_pool_load_incomplete | OFF | | Innodb_buffer_pool_pages_data | 609103 | | Innodb_buffer_pool_bytes_data | 9979543552 | | Innodb_buffer_pool_pages_dirty | 19465 | | Innodb_buffer_pool_bytes_dirty | 318914560 | | Innodb_buffer_pool_pages_flushed | 0 | | Innodb_buffer_pool_pages_free | 299441 | | Innodb_buffer_pool_pages_made_not_young | 0 | | Innodb_buffer_pool_pages_made_young | 107 | | Innodb_buffer_pool_pages_misc | 0 | | Innodb_buffer_pool_pages_old | 224824 | | Innodb_buffer_pool_pages_total | 908544 | | Innodb_buffer_pool_pages_lru_flushed | 0 | | Innodb_buffer_pool_pages_lru_freed | 0 | | Innodb_buffer_pool_pages_split | 726 | | Innodb_buffer_pool_read_ahead_rnd | 0 | | Innodb_buffer_pool_read_ahead | 3 | | Innodb_buffer_pool_read_ahead_evicted | 0 | | Innodb_buffer_pool_read_requests | 0 | | Innodb_buffer_pool_reads | 604346 | | Innodb_buffer_pool_wait_free | 0 | | Innodb_buffer_pool_write_requests | 3639341 | +-----------------------------------------+--------------------------------------------------+ 25 rows in set (0.000 sec)
MariaDB [(none)]> SHOW VARIABLES LIKE 'innodb_buffer_pool%'; +-------------------------------------+----------------+ | Variable_name | Value | +-------------------------------------+----------------+ | innodb_buffer_pool_chunk_size | 134217728 | | innodb_buffer_pool_dump_at_shutdown | ON | | innodb_buffer_pool_dump_now | OFF | | innodb_buffer_pool_dump_pct | 80 | | innodb_buffer_pool_filename | ib_buffer_pool | | innodb_buffer_pool_load_abort | OFF | | innodb_buffer_pool_load_at_startup | ON | | innodb_buffer_pool_load_now | OFF | | innodb_buffer_pool_size | 15032385536 | +-------------------------------------+----------------+ 9 rows in set (0.000 sec)
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Hi Daniel, I filed https://jira.mariadb.org/browse/MDEV-31308 for the accidentally disabled-by-default trx_rseg_history_len. The counter innodb_buffer_pool_read_requests was refactored in MDEV-26827 (MariaDB Server 10.6.13). The monitor counter and the status variable are supposed to get the data straight from the global variable buf_pool.stat.n_page_gets. For the monitor counter, a function is called to copy the value. The status variable is directly pointing to the variable. However, this is a sharded variable, so the status variable would only reflect the first shard. Based on https://jira.mariadb.org/browse/MDEV-21212 we must retain this variable as sharded and the reporting of the status variable must be corrected. I filed https://jira.mariadb.org/browse/MDEV-31309 for this. Thank you for your input! Marko
participants (2)
-
mariadb＠Biblestuph.com -
Marko Mäkelä