[MDEV-32176] Contention in ha_innobase::info_low (dict_table::lock_mutex_lock) - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.6, 10.11, 11.3(EOL), 11.4
Fix Version/s: 10.6.19, 10.11.9, 11.1.6, 11.2.5, 11.4.3, 11.5.2
Component/s: Storage Engine - InnoDB
Labels:
- performance

Description

Running sysbench with Intel's VTune, I've noticed there is large-ish contention in ha_innobase::info_low(), if flag contains HA_STATUS_VARIABLE.

It is a cached workload, database is started with large enough buffer pool 10G.
sysbench is run for 1 table x 1000000 rows, oltp_point_select, 400 users.

.\sysbench.exe oltp_point_select --table-size=10000000 --mysql-user=root --report-interval=1 --time=30 --threads=400 --point-selects=0 --mysql-db=sbtest --mysql-ssl=off --histogram=1 run

I'm attaching the flamegraph screenshots (sorry for this, but it does not seem to be possible to export that in svg from VTune)

The code in question is this

		ib_table->stats_mutex_lock();

		ut_a(ib_table->stat_initialized);

		n_rows = ib_table->stat_n_rows;

		stat_clustered_index_size

			= ib_table->stat_clustered_index_size;

		stat_sum_of_other_index_sizes

			= ib_table->stat_sum_of_other_index_sizes;

		ib_table->stats_mutex_unlock();

the callstack is

ntdll.dll ! ZwWaitForAlertByThreadId

ntdll.dll ! RtlpWaitOnAddressWithTimeout + 0x80

ntdll.dll ! RtlpWaitOnAddress + 0xd7

ntdll.dll ! RtlWaitOnAddress + 0x12

KERNELBASE.dll ! WaitOnAddress + 0x32

server.dll ! srw_mutex_impl<1>::wait + 0x18 - srw_lock.cc:202

server.dll ! srw_mutex_impl<1>::wait_and_lock + 0x60 - srw_lock.cc:324

server.dll ! srw_mutex_impl<1>::wr_lock + 0x10 - srw_lock.h:134

server.dll ! dict_table_t::lock_mutex_lock + 0x7 - dict0mem.h:2011

server.dll ! dict_table_t::stats_mutex_lock - dict0mem.h:2039

server.dll ! ha_innobase::info_low + 0x202 - ha_innodb.cc:14787

server.dll ! make_join_statistics + 0x20c - sql_select.cc:5499

server.dll ! JOIN::optimize_inner + 0x1cff - sql_select.cc:2625

server.dll ! JOIN::optimize + 0x8b - sql_select.cc:1944

server.dll ! mysql_select + 0x2e1 - sql_select.cc:5235

server.dll ! handle_select + 0x1f9 - sql_select.cc:628

server.dll ! execute_sqlcom_select + 0x2e5 - sql_parse.cc:6012

server.dll ! mysql_execute_command + 0xac6 - sql_parse.cc:3911

server.dll ! Prepared_statement::execute + 0x2b3 - sql_prepare.cc:5027

...

It seems like mutual exclusion is an overkill here, as no data is being changed. Perhaps a slim rwlock would be better?

Attachments

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

contention_larger_view.png
59 kB
2023-09-15 09:34
ha_innobase_info_low_contention.png
50 kB
2023-09-15 09:34
info_low_point_select.patch.png
34 kB
2024-06-24 09:54
info_low_point_select.pre-patch.png
31 kB
2024-06-24 09:54

Issue Links

causes

MDEV-35046 SIGSEGV in list_delete in optimized builds when using pseudo_slave_mode

Closed

relates to

MDEV-25029 Reduce dict_sys mutex contention for read-only workload

Closed

MDEV-33966 sysbench performance regression with concurrent workloads

Stalled

Activity

Ascending order - Click to sort in descending order

Vladislav Vaintroub created issue - 2023-09-15 09:40

Vladislav Vaintroub made changes - 2023-09-15 09:40

Field	Original Value	New Value
Description	Running sysbench with Intel's VTune, I've noticed there is large-ish contention in ha_innobase::info_low(flag), if flag contains HA_STATUS_VARIABLE. sysbench is run for 1 table x 1000000 rows, oltp_point_select, 400 users ``` .\sysbench.exe oltp_point_select --table-size=10000000 --mysql-user=root --report-interval=1 --time=30 --threads=400 --point-selects=0 --mysql-db=sbtest --mysql-ssl=off --mysql-host=. --histogram=1 run ``` I'm attaching the flamegraph screenshots (sorry for this, but it does not seem to be possible to export that in svg from VTune) The code in question is this {code:C++} ib_table->stats_mutex_lock(); ut_a(ib_table->stat_initialized); n_rows = ib_table->stat_n_rows; stat_clustered_index_size = ib_table->stat_clustered_index_size; stat_sum_of_other_index_sizes = ib_table->stat_sum_of_other_index_sizes; ib_table->stats_mutex_unlock(); {code} It seems like mutual exclusion is an overkill here, as no data is being changed. Perhaps a slim rwlock would be better?	Running sysbench with Intel's VTune, I've noticed there is large-ish contention in ha_innobase::info_low(), if flag contains HA_STATUS_VARIABLE. sysbench is run for 1 table x 1000000 rows, oltp_point_select, 400 users ``` .\sysbench.exe oltp_point_select --table-size=10000000 --mysql-user=root --report-interval=1 --time=30 --threads=400 --point-selects=0 --mysql-db=sbtest --mysql-ssl=off --mysql-host=. --histogram=1 run ``` I'm attaching the flamegraph screenshots (sorry for this, but it does not seem to be possible to export that in svg from VTune) The code in question is this {code:c++} ib_table->stats_mutex_lock(); ut_a(ib_table->stat_initialized); n_rows = ib_table->stat_n_rows; stat_clustered_index_size = ib_table->stat_clustered_index_size; stat_sum_of_other_index_sizes = ib_table->stat_sum_of_other_index_sizes; ib_table->stats_mutex_unlock(); {code} It seems like mutual exclusion is an overkill here, as no data is being changed. Perhaps a slim rwlock would be better?

Vladislav Vaintroub made changes - 2023-09-15 09:42

Description

Running sysbench with Intel's VTune, I've noticed there is large-ish contention in ha_innobase::info_low(), if flag contains HA_STATUS_VARIABLE.

sysbench is run for 1 table x 1000000 rows, oltp_point_select, 400 users

```
.\sysbench.exe oltp_point_select --table-size=10000000 --mysql-user=root --report-interval=1 --time=30 --threads=400 --point-selects=0 --mysql-db=sbtest --mysql-ssl=off --mysql-host=. --histogram=1 run ```

I'm attaching the flamegraph screenshots (sorry for this, but it does not seem to be possible to export that in svg from VTune)

The code in question is this
{code:c++}
ib_table->stats_mutex_lock();

ut_a(ib_table->stat_initialized);

n_rows = ib_table->stat_n_rows;

stat_clustered_index_size
= ib_table->stat_clustered_index_size;

stat_sum_of_other_index_sizes
= ib_table->stat_sum_of_other_index_sizes;

ib_table->stats_mutex_unlock();
{code}
It seems like mutual exclusion is an overkill here, as no data is being changed. Perhaps a slim rwlock would be better?

Running sysbench with Intel's VTune, I've noticed there is large-ish contention in ha_innobase::info_low(), if flag contains HA_STATUS_VARIABLE.

sysbench is run for 1 table x 1000000 rows, oltp_point_select, 400 users

.\sysbench.exe oltp_point_select --table-size=10000000 --mysql-user=root --report-interval=1 --time=30 --threads=400 --point-selects=0 --mysql-db=sbtest --mysql-ssl=off --histogram=1 run

I'm attaching the flamegraph screenshots (sorry for this, but it does not seem to be possible to export that in svg from VTune)

The code in question is this
{code:c++}
ib_table->stats_mutex_lock();

ut_a(ib_table->stat_initialized);

n_rows = ib_table->stat_n_rows;

stat_clustered_index_size
= ib_table->stat_clustered_index_size;

stat_sum_of_other_index_sizes
= ib_table->stat_sum_of_other_index_sizes;

ib_table->stats_mutex_unlock();
{code}
It seems like mutual exclusion is an overkill here, as no data is being changed. Perhaps a slim rwlock would be better?

Vladislav Vaintroub made changes - 2023-09-15 09:53

Description

Running sysbench with Intel's VTune, I've noticed there is large-ish contention in ha_innobase::info_low(), if flag contains HA_STATUS_VARIABLE.

sysbench is run for 1 table x 1000000 rows, oltp_point_select, 400 users

.\sysbench.exe oltp_point_select --table-size=10000000 --mysql-user=root --report-interval=1 --time=30 --threads=400 --point-selects=0 --mysql-db=sbtest --mysql-ssl=off --histogram=1 run

I'm attaching the flamegraph screenshots (sorry for this, but it does not seem to be possible to export that in svg from VTune)

The code in question is this
{code:c++}
ib_table->stats_mutex_lock();

ut_a(ib_table->stat_initialized);

n_rows = ib_table->stat_n_rows;

stat_clustered_index_size
= ib_table->stat_clustered_index_size;

stat_sum_of_other_index_sizes
= ib_table->stat_sum_of_other_index_sizes;

ib_table->stats_mutex_unlock();
{code}
It seems like mutual exclusion is an overkill here, as no data is being changed. Perhaps a slim rwlock would be better?

Running sysbench with Intel's VTune, I've noticed there is large-ish contention in ha_innobase::info_low(), if flag contains HA_STATUS_VARIABLE.

sysbench is run for 1 table x 1000000 rows, oltp_point_select, 400 users. It is a cached workload, database is started with large enough buffer pool 10G.

.\sysbench.exe oltp_point_select --table-size=10000000 --mysql-user=root --report-interval=1 --time=30 --threads=400 --point-selects=0 --mysql-db=sbtest --mysql-ssl=off --histogram=1 run

I'm attaching the flamegraph screenshots (sorry for this, but it does not seem to be possible to export that in svg from VTune)

The code in question is this
{code:c++}
ib_table->stats_mutex_lock();

ut_a(ib_table->stat_initialized);

n_rows = ib_table->stat_n_rows;

stat_clustered_index_size
= ib_table->stat_clustered_index_size;

stat_sum_of_other_index_sizes
= ib_table->stat_sum_of_other_index_sizes;

ib_table->stats_mutex_unlock();
{code}
the callstack is
{noformat}
ntdll.dll ! ZwWaitForAlertByThreadId
ntdll.dll ! RtlpWaitOnAddressWithTimeout + 0x80
ntdll.dll ! RtlpWaitOnAddress + 0xd7
ntdll.dll ! RtlWaitOnAddress + 0x12
KERNELBASE.dll ! WaitOnAddress + 0x32
server.dll ! srw_mutex_impl<1>::wait + 0x18 - srw_lock.cc:202
server.dll ! srw_mutex_impl<1>::wait_and_lock + 0x60 - srw_lock.cc:324
server.dll ! srw_mutex_impl<1>::wr_lock + 0x10 - srw_lock.h:134
server.dll ! dict_table_t::lock_mutex_lock + 0x7 - dict0mem.h:2011
server.dll ! dict_table_t::stats_mutex_lock - dict0mem.h:2039
server.dll ! ha_innobase::info_low + 0x202 - ha_innodb.cc:14787
server.dll ! make_join_statistics + 0x20c - sql_select.cc:5499
server.dll ! JOIN::optimize_inner + 0x1cff - sql_select.cc:2625
server.dll ! JOIN::optimize + 0x8b - sql_select.cc:1944
...
{noformat}
It seems like mutual exclusion is an overkill here, as no data is being changed. Perhaps a slim rwlock would be better?

Vladislav Vaintroub made changes - 2023-09-15 09:57

Description

Running sysbench with Intel's VTune, I've noticed there is large-ish contention in ha_innobase::info_low(), if flag contains HA_STATUS_VARIABLE.

sysbench is run for 1 table x 1000000 rows, oltp_point_select, 400 users. It is a cached workload, database is started with large enough buffer pool 10G.

.\sysbench.exe oltp_point_select --table-size=10000000 --mysql-user=root --report-interval=1 --time=30 --threads=400 --point-selects=0 --mysql-db=sbtest --mysql-ssl=off --histogram=1 run

I'm attaching the flamegraph screenshots (sorry for this, but it does not seem to be possible to export that in svg from VTune)

The code in question is this
{code:c++}
ib_table->stats_mutex_lock();

ut_a(ib_table->stat_initialized);

n_rows = ib_table->stat_n_rows;

stat_clustered_index_size
= ib_table->stat_clustered_index_size;

stat_sum_of_other_index_sizes
= ib_table->stat_sum_of_other_index_sizes;

ib_table->stats_mutex_unlock();
{code}
the callstack is
{noformat}
ntdll.dll ! ZwWaitForAlertByThreadId
ntdll.dll ! RtlpWaitOnAddressWithTimeout + 0x80
ntdll.dll ! RtlpWaitOnAddress + 0xd7
ntdll.dll ! RtlWaitOnAddress + 0x12
KERNELBASE.dll ! WaitOnAddress + 0x32
server.dll ! srw_mutex_impl<1>::wait + 0x18 - srw_lock.cc:202
server.dll ! srw_mutex_impl<1>::wait_and_lock + 0x60 - srw_lock.cc:324
server.dll ! srw_mutex_impl<1>::wr_lock + 0x10 - srw_lock.h:134
server.dll ! dict_table_t::lock_mutex_lock + 0x7 - dict0mem.h:2011
server.dll ! dict_table_t::stats_mutex_lock - dict0mem.h:2039
server.dll ! ha_innobase::info_low + 0x202 - ha_innodb.cc:14787
server.dll ! make_join_statistics + 0x20c - sql_select.cc:5499
server.dll ! JOIN::optimize_inner + 0x1cff - sql_select.cc:2625
server.dll ! JOIN::optimize + 0x8b - sql_select.cc:1944
...
{noformat}
It seems like mutual exclusion is an overkill here, as no data is being changed. Perhaps a slim rwlock would be better?

Running sysbench with Intel's VTune, I've noticed there is large-ish contention in ha_innobase::info_low(), if flag contains HA_STATUS_VARIABLE.

It is a cached workload, database is started with large enough buffer pool 10G.
sysbench is run for 1 table x 1000000 rows, oltp_point_select, 400 users.

.\sysbench.exe oltp_point_select --table-size=10000000 --mysql-user=root --report-interval=1 --time=30 --threads=400 --point-selects=0 --mysql-db=sbtest --mysql-ssl=off --histogram=1 run

I'm attaching the flamegraph screenshots (sorry for this, but it does not seem to be possible to export that in svg from VTune)

The code in question is this
{code:c++}
ib_table->stats_mutex_lock();

ut_a(ib_table->stat_initialized);

n_rows = ib_table->stat_n_rows;

stat_clustered_index_size
= ib_table->stat_clustered_index_size;

stat_sum_of_other_index_sizes
= ib_table->stat_sum_of_other_index_sizes;

ib_table->stats_mutex_unlock();
{code}
the callstack is
{noformat}
CPU Time
1 of 9: 76.7% (1.946s of 2.538s)

ntdll.dll ! ZwWaitForAlertByThreadId
ntdll.dll ! RtlpWaitOnAddressWithTimeout + 0x80
ntdll.dll ! RtlpWaitOnAddress + 0xd7
ntdll.dll ! RtlWaitOnAddress + 0x12
KERNELBASE.dll ! WaitOnAddress + 0x32
server.dll ! srw_mutex_impl<1>::wait + 0x18 - srw_lock.cc:202
server.dll ! srw_mutex_impl<1>::wait_and_lock + 0x60 - srw_lock.cc:324
server.dll ! srw_mutex_impl<1>::wr_lock + 0x10 - srw_lock.h:134
server.dll ! dict_table_t::lock_mutex_lock + 0x7 - dict0mem.h:2011
server.dll ! dict_table_t::stats_mutex_lock - dict0mem.h:2039
server.dll ! ha_innobase::info_low + 0x202 - ha_innodb.cc:14787
server.dll ! make_join_statistics + 0x20c - sql_select.cc:5499
server.dll ! JOIN::optimize_inner + 0x1cff - sql_select.cc:2625
server.dll ! JOIN::optimize + 0x8b - sql_select.cc:1944
server.dll ! mysql_select + 0x2e1 - sql_select.cc:5235
server.dll ! handle_select + 0x1f9 - sql_select.cc:628
server.dll ! execute_sqlcom_select + 0x2e5 - sql_parse.cc:6012
server.dll ! mysql_execute_command + 0xac6 - sql_parse.cc:3911
server.dll ! Prepared_statement::execute + 0x2b3 - sql_prepare.cc:5027
...
{noformat}
It seems like mutual exclusion is an overkill here, as no data is being changed. Perhaps a slim rwlock would be better?

Vladislav Vaintroub made changes - 2023-09-15 09:57

Description

Running sysbench with Intel's VTune, I've noticed there is large-ish contention in ha_innobase::info_low(), if flag contains HA_STATUS_VARIABLE.

It is a cached workload, database is started with large enough buffer pool 10G.
sysbench is run for 1 table x 1000000 rows, oltp_point_select, 400 users.

.\sysbench.exe oltp_point_select --table-size=10000000 --mysql-user=root --report-interval=1 --time=30 --threads=400 --point-selects=0 --mysql-db=sbtest --mysql-ssl=off --histogram=1 run

I'm attaching the flamegraph screenshots (sorry for this, but it does not seem to be possible to export that in svg from VTune)

The code in question is this
{code:c++}
ib_table->stats_mutex_lock();

ut_a(ib_table->stat_initialized);

n_rows = ib_table->stat_n_rows;

stat_clustered_index_size
= ib_table->stat_clustered_index_size;

stat_sum_of_other_index_sizes
= ib_table->stat_sum_of_other_index_sizes;

ib_table->stats_mutex_unlock();
{code}
the callstack is
{noformat}
ntdll.dll ! ZwWaitForAlertByThreadId
ntdll.dll ! RtlpWaitOnAddressWithTimeout + 0x80
ntdll.dll ! RtlpWaitOnAddress + 0xd7
ntdll.dll ! RtlWaitOnAddress + 0x12
KERNELBASE.dll ! WaitOnAddress + 0x32
server.dll ! srw_mutex_impl<1>::wait + 0x18 - srw_lock.cc:202
server.dll ! srw_mutex_impl<1>::wait_and_lock + 0x60 - srw_lock.cc:324
server.dll ! srw_mutex_impl<1>::wr_lock + 0x10 - srw_lock.h:134
server.dll ! dict_table_t::lock_mutex_lock + 0x7 - dict0mem.h:2011
server.dll ! dict_table_t::stats_mutex_lock - dict0mem.h:2039
server.dll ! ha_innobase::info_low + 0x202 - ha_innodb.cc:14787
server.dll ! make_join_statistics + 0x20c - sql_select.cc:5499
server.dll ! JOIN::optimize_inner + 0x1cff - sql_select.cc:2625
server.dll ! JOIN::optimize + 0x8b - sql_select.cc:1944
server.dll ! mysql_select + 0x2e1 - sql_select.cc:5235
server.dll ! handle_select + 0x1f9 - sql_select.cc:628
server.dll ! execute_sqlcom_select + 0x2e5 - sql_parse.cc:6012
server.dll ! mysql_execute_command + 0xac6 - sql_parse.cc:3911
server.dll ! Prepared_statement::execute + 0x2b3 - sql_prepare.cc:5027
...
{noformat}
It seems like mutual exclusion is an overkill here, as no data is being changed. Perhaps a slim rwlock would be better?

Vladislav Vaintroub made changes - 2024-05-28 14:35

Assignee

Marko Mäkelä [ marko ]

Vladislav Vaintroub added a comment - 2024-05-28 14:37

assigning to @marko. I see it is still being unassigned, after almost I year

Vladislav Vaintroub added a comment - 2024-05-28 14:37 assigning to @marko. I see it is still being unassigned, after almost I year

Vladislav Vaintroub made changes - 2024-05-28 14:38

Link

This issue relates to MDEV-33966 [ MDEV-33966 ]

Marko Mäkelä made changes - 2024-05-28 15:03

Fix Version/s		10.6 [ 24028 ]
Fix Version/s		10.11 [ 27614 ]
Fix Version/s		11.4 [ 29301 ]
Affects Version/s		10.6 [ 24028 ]
Affects Version/s		10.11 [ 27614 ]
Affects Version/s		11.4 [ 29301 ]

Marko Mäkelä made changes - 2024-05-28 15:03

Status

Open [ 1 ]

In Progress [ 3 ]

Marko Mäkelä made changes - 2024-06-04 06:02

Link

This issue relates to ~~MDEV-25029~~ [ ~~MDEV-25029~~ ]

Marko Mäkelä added a comment - 2024-06-07 12:28

There are also a couple other places where it indeed would suffice to hold a shared latch, both when accessing table locks or table statistics. We can also attempt lock elision (~~MDEV-26769~~) in ha_innobase::info_low(HA_STATUS_VARIABLE).

Somewhat related to this, I had written a note that in innobase_build_v_templ() it would suffice to hold an exclusive per-table latch, instead of holding an exclusive dict_sys.latch. I would fix also that as part of this.

Marko Mäkelä added a comment - 2024-06-07 12:28 There are also a couple other places where it indeed would suffice to hold a shared latch, both when accessing table locks or table statistics. We can also attempt lock elision ( MDEV-26769 ) in ha_innobase::info_low(HA_STATUS_VARIABLE) . Somewhat related to this, I had written a note that in innobase_build_v_templ() it would suffice to hold an exclusive per-table latch, instead of holding an exclusive dict_sys.latch . I would fix also that as part of this.

Marko Mäkelä added a comment - 2024-06-07 12:44

https://github.com/MariaDB/server/pull/3320 includes also a tentative fix of mdcallag’s ~~MDEV-34178~~, which could be interesting to test at the same time.

Marko Mäkelä added a comment - 2024-06-07 12:44 https://github.com/MariaDB/server/pull/3320 includes also a tentative fix of mdcallag ’s MDEV-34178 , which could be interesting to test at the same time.

Marko Mäkelä made changes - 2024-06-07 12:44

Assignee	Marko Mäkelä [ marko ]	Vladislav Vaintroub [ wlad ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Vladislav Vaintroub made changes - 2024-06-24 09:54

Attachment		info_low_point_select.patch.png [ 73695 ]
Attachment		info_low_point_select.pre-patch.png [ 73696 ]

Vladislav Vaintroub added a comment - 2024-06-24 09:55

confirm that patch reduces CPU time in the ha_innobase::info_low in the original test from 1.2% to 0.3%

Vladislav Vaintroub added a comment - 2024-06-24 09:55 confirm that patch reduces CPU time in the ha_innobase::info_low in the original test from 1.2% to 0.3%

Vladislav Vaintroub made changes - 2024-06-24 09:56

Status

In Review [ 10002 ]

Stalled [ 10000 ]

Marko Mäkelä made changes - 2024-06-24 12:31

Status

Stalled [ 10000 ]

In Testing [ 10301 ]

Marko Mäkelä made changes - 2024-06-24 12:32

Assignee

Vladislav Vaintroub [ wlad ]

Matthias Leich [ mleich ]

Marko Mäkelä added a comment - 2024-06-28 13:50

Pushed to 10.6 and merged to 10.11 (with no conflicts).

Marko Mäkelä added a comment - 2024-06-28 13:50 Pushed to 10.6 and merged to 10.11 (with no conflicts).

Marko Mäkelä made changes - 2024-06-28 13:50

issue.field.resolutiondate

2024-06-28 13:50:04.0

2024-06-28 13:50:04.235

Marko Mäkelä made changes - 2024-06-28 13:50

Fix Version/s		10.6.19 [ 29833 ]
Fix Version/s		10.11.9 [ 29834 ]
Fix Version/s		11.1.6 [ 29835 ]
Fix Version/s		11.2.5 [ 29836 ]
Fix Version/s		11.4.3 [ 29837 ]
Fix Version/s		11.5.2 [ 29838 ]
Fix Version/s	10.6 [ 24028 ]
Fix Version/s	10.11 [ 27614 ]
Fix Version/s	11.4 [ 29301 ]
Assignee	Matthias Leich [ mleich ]	Marko Mäkelä [ marko ]
Resolution		Fixed [ 1 ]
Status	In Testing [ 10301 ]	Closed [ 6 ]

Matthias Leich added a comment - 2024-07-01 09:33

origin/10.6-MDEV-32176 e10acdf6c4624f891fbc22116e859ec3e7f86d9a 2024-06-24T15:53:41+03:00

behaved well in RQG testing.

Matthias Leich added a comment - 2024-07-01 09:33 origin/10.6-MDEV-32176 e10acdf6c4624f891fbc22116e859ec3e7f86d9a 2024-06-24T15:53:41+03:00 behaved well in RQG testing.

Roel Van de Paar made changes - 2024-10-09 00:04

Link

This issue causes ~~MDEV-35046~~ [ ~~MDEV-35046~~ ]

People

Assignee:: Marko Mäkelä

Reporter:: Vladislav Vaintroub

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Dates

Created:: 2023-09-15 09:40

Updated:: 2024-10-09 00:04

Resolved:: 2024-06-28 13:50

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates

Git Integration