[MDEV-22722] Assertion "inited==NONE" failed in handler::ha_index_init on the slave during UPDATE - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Blocker
Resolution: Fixed
Affects Version/s: 10.5
Fix Version/s: 10.5.4
Component/s: Replication, Server
Labels:
- regression

Description

Reproducible on 10.5, with Myisam, not with InnoDB.

source include/master-slave.inc;

create table t1 (i1 int, a1 text, unique key i1 (a1)) engine=myisam;

insert into t1 values (1,1);

update t1 set a1 = 'd' limit 1;

sync_slave_with_master;

connection slave;

connection master;

drop table t1;

--source include/rpl_end.inc

10.5 8569dac1ec9f6853a0b2f3
#3 <signal handler called>
#4 0x00007fb74811b428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#5 0x00007fb74811d02a in __GI_abort () at abort.c:89
#6 0x00007fb748113bd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x563f42ef17d9 "inited==NONE", file=file@entry=0x563f42ef17a8 "/10.5/sql/handler.h", line=line@entry=3323, function=function@entry=0x563f42ef5960 <handler::ha_index_init(unsigned int, bool)::__PRETTY_FUNCTION__> "int handler::ha_index_init(uint, bool)") at assert.c:92
#7 0x00007fb748113c82 in __GI___assert_fail (assertion=0x563f42ef17d9 "inited==NONE", file=0x563f42ef17a8 "/10.5/sql/handler.h", line=3323, function=0x563f42ef5960 <handler::ha_index_init(unsigned int, bool)::__PRETTY_FUNCTION__> "int handler::ha_index_init(uint, bool)") at assert.c:101
#8 0x0000563f420913dd in handler::ha_index_init (this=0x7fb6f0038740, idx=0, sorted=false) at /10.5/sql/handler.h:3323
#9 0x0000563f424b441a in handler::check_duplicate_long_entry_key (this=0x7fb6f0038740, new_rec=0x7fb6f00382d8 "\370\001", key_no=0) at /10.5/sql/handler.cc:6629
#10 0x0000563f424b4df8 in handler::check_duplicate_long_entries_update (this=0x7fb6f0038740, new_rec=0x7fb6f00382d8 "\370\001") at /10.5/sql/handler.cc:6761
#11 0x0000563f424b61ec in handler::ha_update_row (this=0x7fb6f0038740, old_data=0x7fb6f00382f0 "\370\001", new_data=0x7fb6f00382d8 "\370\001") at /10.5/sql/handler.cc:7031
#12 0x0000563f4261de7f in Update_rows_log_event::do_exec_row (this=0x7fb6f0960af8, rgi=0x7fb6f0000a90) at /10.5/sql/log_event_server.cc:8325
#13 0x0000563f426158ed in Rows_log_event::do_apply_event (this=0x7fb6f0960af8, rgi=0x7fb6f0000a90) at /10.5/sql/log_event_server.cc:5650
#14 0x0000563f42045df5 in Log_event::apply_event (this=0x7fb6f0960af8, rgi=0x7fb6f0000a90) at /10.5/sql/log_event.h:1496
#15 0x0000563f420388e4 in apply_event_and_update_pos_apply (ev=0x7fb6f0960af8, thd=0x7fb6f0001598, rgi=0x7fb6f0000a90, reason=0) at /10.5/sql/slave.cc:4003
#16 0x0000563f42038ec7 in apply_event_and_update_pos (ev=0x7fb6f0960af8, thd=0x7fb6f0001598, rgi=0x7fb6f0000a90) at /10.5/sql/slave.cc:4165
#17 0x0000563f42039880 in exec_relay_log_event (thd=0x7fb6f0001598, rli=0x563f46015458, serial_rgi=0x7fb6f0000a90) at /10.5/sql/slave.cc:4486
#18 0x0000563f4203d1b8 in handle_slave_sql (arg=0x563f46013790) at /10.5/sql/slave.cc:5659
#19 0x0000563f42743efc in pfs_spawn_thread (arg=0x7fb7041f96e8) at /10.5/storage/perfschema/pfs.cc:2201
#20 0x00007fb748f5c6ba in start_thread (arg=0x7fb73c2f3700) at pthread_create.c:333
#21 0x00007fb7481ed41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Attachments

Issue Links

duplicates

MDEV-22847 Server crashes in handler::check_duplicate_long_entry_key upon executing row event

Closed

relates to

MDEV-371 Unique indexes for blobs

Closed

MDEV-18720 Assertion `inited==NONE' failed in ha_index_init upon update on versioned table with key on blob

Closed

Activity

Ascending order - Click to sort in descending order

Alice Sherepa created issue - 2020-05-26 14:00

Alice Sherepa made changes - 2020-05-26 14:00

Field	Original Value	New Value
Link		This issue relates to ~~MDEV-18720~~ [ ~~MDEV-18720~~ ]

Alice Sherepa made changes - 2020-05-26 14:02

Description

Reproducible on 10.5, with Myisam, not with InnoDB.

{code:sql}
source include/master-slave.inc;

create table t1 (i1 int, a1 text, unique key i1 (a1)) engine=myisam;
insert into t1 values (0,null);
update t1 set a1 = 'd' limit 1;

sync_slave_with_master;
connection slave;

connection master;
drop table t1;

--source include/rpl_end.inc
{code}

{noformat:title=10.5 8569dac1ec9f6853a0b2f3}
#3 <signal handler called>
#4 0x00007fa6a1061428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#5 0x00007fa6a106302a in __GI_abort () at abort.c:89
#6 0x00007fa6a1059bd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x55f2f211f7d9 "inited==NONE", file=file@entry=0x55f2f211f7a8 "/10.5/sql/handler.h", line=line@entry=3323, function=function@entry=0x55f2f2123960 <handler::ha_index_init(unsigned int, bool)::__PRETTY_FUNCTION__> "int handler::ha_index_init(uint, bool)") at assert.c:92
#7 0x00007fa6a1059c82 in __GI___assert_fail (assertion=0x55f2f211f7d9 "inited==NONE", file=0x55f2f211f7a8 "/10.5/sql/handler.h", line=3323, function=0x55f2f2123960 <handler::ha_index_init(unsigned int, bool)::__PRETTY_FUNCTION__> "int handler::ha_index_init(uint, bool)") at assert.c:101
#8 0x000055f2f12bf3dd in handler::ha_index_init (this=0x7fa658038740, idx=0, sorted=false) at /10.5/sql/handler.h:3323
#9 0x000055f2f16e241a in handler::check_duplicate_long_entry_key (this=0x7fa658038740, new_rec=0x7fa6580382d8 "\370", key_no=0) at /10.5/sql/handler.cc:6629
#10 0x000055f2f16e2df8 in handler::check_duplicate_long_entries_update (this=0x7fa658038740, new_rec=0x7fa6580382d8 "\370") at /10.5/sql/handler.cc:6761
#11 0x000055f2f16e41ec in handler::ha_update_row (this=0x7fa658038740, old_data=0x7fa6580382f0 "\376", new_data=0x7fa6580382d8 "\370") at /10.5/sql/handler.cc:7031
#12 0x000055f2f184be7f in Update_rows_log_event::do_exec_row (this=0x7fa658960a58, rgi=0x7fa658000a90) at /10.5/sql/log_event_server.cc:8325
#13 0x000055f2f18438ed in Rows_log_event::do_apply_event (this=0x7fa658960a58, rgi=0x7fa658000a90) at /10.5/sql/log_event_server.cc:5650
#14 0x000055f2f1273df5 in Log_event::apply_event (this=0x7fa658960a58, rgi=0x7fa658000a90) at /10.5/sql/log_event.h:1496
#15 0x000055f2f12668e4 in apply_event_and_update_pos_apply (ev=0x7fa658960a58, thd=0x7fa658001598, rgi=0x7fa658000a90, reason=0) at /10.5/sql/slave.cc:4003
#16 0x000055f2f1266ec7 in apply_event_and_update_pos (ev=0x7fa658960a58, thd=0x7fa658001598, rgi=0x7fa658000a90) at /10.5/sql/slave.cc:4165
#17 0x000055f2f1267880 in exec_relay_log_event (thd=0x7fa658001598, rli=0x55f2f50b02d8, serial_rgi=0x7fa658000a90) at /10.5/sql/slave.cc:4486
#18 0x000055f2f126b1b8 in handle_slave_sql (arg=0x55f2f50ae610) at /10.5/sql/slave.cc:5659
#19 0x000055f2f1971efc in pfs_spawn_thread (arg=0x7fa65c1ff1b8) at /10.5/storage/perfschema/pfs.cc:2201
#20 0x00007fa6a1ea26ba in start_thread (arg=0x7fa694237700) at pthread_create.c:333
#21 0x00007fa6a113341d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
{noformat}

on non-debug build:
{noformat}
ast_Errno 1032
Last_Error Could not execute Update_rows_v1 event on table test.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log master-bin.000001, end_log_pos 915
{noformat}

Reproducible on 10.5, with Myisam, not with InnoDB.

{code:sql}
source include/master-slave.inc;

create table t1 (i1 int, a1 text, unique key i1 (a1)) engine=myisam;
insert into t1 values (1,1);
update t1 set a1 = 'd' limit 1;

sync_slave_with_master;
connection slave;

connection master;
drop table t1;

--source include/rpl_end.inc
{code}

{noformat:title=10.5 8569dac1ec9f6853a0b2f3}
#3 <signal handler called>
#4 0x00007fb74811b428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#5 0x00007fb74811d02a in __GI_abort () at abort.c:89
#6 0x00007fb748113bd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x563f42ef17d9 "inited==NONE", file=file@entry=0x563f42ef17a8 "/10.5/sql/handler.h", line=line@entry=3323, function=function@entry=0x563f42ef5960 <handler::ha_index_init(unsigned int, bool)::__PRETTY_FUNCTION__> "int handler::ha_index_init(uint, bool)") at assert.c:92
#7 0x00007fb748113c82 in __GI___assert_fail (assertion=0x563f42ef17d9 "inited==NONE", file=0x563f42ef17a8 "/10.5/sql/handler.h", line=3323, function=0x563f42ef5960 <handler::ha_index_init(unsigned int, bool)::__PRETTY_FUNCTION__> "int handler::ha_index_init(uint, bool)") at assert.c:101
#8 0x0000563f420913dd in handler::ha_index_init (this=0x7fb6f0038740, idx=0, sorted=false) at /10.5/sql/handler.h:3323
#9 0x0000563f424b441a in handler::check_duplicate_long_entry_key (this=0x7fb6f0038740, new_rec=0x7fb6f00382d8 "\370\001", key_no=0) at /10.5/sql/handler.cc:6629
#10 0x0000563f424b4df8 in handler::check_duplicate_long_entries_update (this=0x7fb6f0038740, new_rec=0x7fb6f00382d8 "\370\001") at /10.5/sql/handler.cc:6761
#11 0x0000563f424b61ec in handler::ha_update_row (this=0x7fb6f0038740, old_data=0x7fb6f00382f0 "\370\001", new_data=0x7fb6f00382d8 "\370\001") at /10.5/sql/handler.cc:7031
#12 0x0000563f4261de7f in Update_rows_log_event::do_exec_row (this=0x7fb6f0960af8, rgi=0x7fb6f0000a90) at /10.5/sql/log_event_server.cc:8325
#13 0x0000563f426158ed in Rows_log_event::do_apply_event (this=0x7fb6f0960af8, rgi=0x7fb6f0000a90) at /10.5/sql/log_event_server.cc:5650
#14 0x0000563f42045df5 in Log_event::apply_event (this=0x7fb6f0960af8, rgi=0x7fb6f0000a90) at /10.5/sql/log_event.h:1496
#15 0x0000563f420388e4 in apply_event_and_update_pos_apply (ev=0x7fb6f0960af8, thd=0x7fb6f0001598, rgi=0x7fb6f0000a90, reason=0) at /10.5/sql/slave.cc:4003
#16 0x0000563f42038ec7 in apply_event_and_update_pos (ev=0x7fb6f0960af8, thd=0x7fb6f0001598, rgi=0x7fb6f0000a90) at /10.5/sql/slave.cc:4165
#17 0x0000563f42039880 in exec_relay_log_event (thd=0x7fb6f0001598, rli=0x563f46015458, serial_rgi=0x7fb6f0000a90) at /10.5/sql/slave.cc:4486
#18 0x0000563f4203d1b8 in handle_slave_sql (arg=0x563f46013790) at /10.5/sql/slave.cc:5659
#19 0x0000563f42743efc in pfs_spawn_thread (arg=0x7fb7041f96e8) at /10.5/storage/perfschema/pfs.cc:2201
#20 0x00007fb748f5c6ba in start_thread (arg=0x7fb73c2f3700) at pthread_create.c:333
#21 0x00007fb7481ed41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

{noformat}

Alice Sherepa made changes - 2020-05-26 14:04

Link

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

Alice Sherepa made changes - 2020-05-26 14:06

Assignee

Sergei Golubchik [ serg ]

Alice Sherepa made changes - 2020-05-26 14:12

Status

Open [ 1 ]

Confirmed [ 10101 ]

Sergei Golubchik made changes - 2020-05-26 14:26

Assignee

Sergei Golubchik [ serg ]

Sachin Setiya [ sachin.setiya.007 ]

Sachin Setiya (Inactive) added a comment - 2020-05-29 08:09

Fails with 10.4 also (after completing ~~MDEV-22747~~ )

Sachin Setiya (Inactive) added a comment - 2020-05-29 08:09 Fails with 10.4 also (after completing MDEV-22747 )

Sachin Setiya (Inactive) added a comment - 2020-05-29 09:17

It fails even without update

source include/master-slave.inc;

create table t1 (i1 int, a1 text unique)engine=myisam;

insert into t1 values (1,1);

sync_slave_with_master;

connection slave;

connection master;

drop table t1;

--source include/rpl_end.inc

Sachin Setiya (Inactive) added a comment - 2020-05-29 09:17 It fails even without update source include/master-slave.inc; create table t1 (i1 int, a1 text unique)engine=myisam; insert into t1 values (1,1); sync_slave_with_master; connection slave; connection master; drop table t1; --source include/rpl_end.inc

Sachin Setiya (Inactive) added a comment - 2020-06-01 16:24

Patch branch bb-10.4-sachin2 and bb-10.5-sachin

Sachin Setiya (Inactive) added a comment - 2020-06-01 16:24 Patch branch bb-10.4-sachin2 and bb-10.5-sachin

Sachin Setiya (Inactive) made changes - 2020-06-01 16:24

Status

Confirmed [ 10101 ]

In Progress [ 3 ]

Sachin Setiya (Inactive) made changes - 2020-06-01 16:24

Assignee	Sachin Setiya [ sachin.setiya.007 ]	Sergei Golubchik [ serg ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Sachin Setiya (Inactive) added a comment - 2020-06-02 06:14

Ideally it should fail for innodb also , needs debugging

Sachin Setiya (Inactive) added a comment - 2020-06-02 06:14 Ideally it should fail for innodb also , needs debugging

Sergei Golubchik made changes - 2020-06-03 15:18

Assignee	Sergei Golubchik [ serg ]	Sachin Setiya [ sachin.setiya.007 ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Sachin Setiya (Inactive) made changes - 2020-06-09 01:26

Assignee	Sachin Setiya [ sachin.setiya.007 ]	Sergei Golubchik [ serg ]
Status	Stalled [ 10000 ]	In Review [ 10002 ]

Elena Stepanova added a comment - 2020-06-09 22:22

~~MDEV-22847~~ is marked as a duplicate of this one.
Some notes:

Representation of the failure without UPDATE is not identical to the initially reported one. The reported one is a debug assertion which happens in the mixed combination (apparently because only UPDATE makes mixed replication switch to RBR, while INSERT doesn't). The reduced version of the test case without UPDATE causes SIGSEGV in the row combination of the test, and it affects both debug and non-debug builds. Here is the stack trace from it:

#3  <signal handler called>

#4  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:286

#5  0x0000560680c94788 in handler::check_duplicate_long_entry_key (this=0x7f22cc038e00, new_rec=0x7f22cc035898 "\370\001", key_no=0) at /data/src/10.5/sql/handler.cc:6645

#6  0x0000560680c94fd1 in handler::check_duplicate_long_entries (this=0x7f22cc038e00, new_rec=0x7f22cc035898 "\370\001") at /data/src/10.5/sql/handler.cc:6726

#7  0x0000560680c95dc9 in handler::ha_write_row (this=0x7f22cc038e00, buf=0x7f22cc035898 "\370\001") at /data/src/10.5/sql/handler.cc:6996

#8  0x0000560680df8af2 in Rows_log_event::write_row (this=0x7f22cc033f28, rgi=0x7f22cc000a90, overwrite=false) at /data/src/10.5/sql/log_event_server.cc:7260

#9  0x0000560680df9747 in Write_rows_log_event::do_exec_row (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event_server.cc:7480

#10 0x0000560680df33d5 in Rows_log_event::do_apply_event (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event_server.cc:5650

#11 0x0000560680829feb in Log_event::apply_event (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event.h:1496

#12 0x000056068081ca58 in apply_event_and_update_pos_apply (ev=0x7f22cc033f28, thd=0x7f22cc001598, rgi=0x7f22cc000a90, reason=0) at /data/src/10.5/sql/slave.cc:4003

#13 0x000056068081d03e in apply_event_and_update_pos (ev=0x7f22cc033f28, thd=0x7f22cc001598, rgi=0x7f22cc000a90) at /data/src/10.5/sql/slave.cc:4165

#14 0x000056068081d990 in exec_relay_log_event (thd=0x7f22cc001598, rli=0x56068406f6d8, serial_rgi=0x7f22cc000a90) at /data/src/10.5/sql/slave.cc:4482

#15 0x00005606808212fd in handle_slave_sql (arg=0x56068406da10) at /data/src/10.5/sql/slave.cc:5659

#16 0x0000560681002b56 in pfs_spawn_thread (arg=0x7f22e01face8) at /data/src/10.5/storage/perfschema/pfs.cc:2201

#17 0x00007f23150824a4 in start_thread (arg=0x7f230c312700) at pthread_create.c:456

#18 0x00007f23131b6d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

both variations are reproducible with InnoDB as well, with the same test cases. I don't know what happened when you tried, please double-check.

it fails on 10.4 after completing ~~MDEV-22747~~ because one of the commits you are backporting introduced the failure. This one:

commit 0515577d128318e1b62511846d88d0c56226168d

Author: Sergei Golubchik

Date: Thu Mar 5 19:19:57 2020 +0100

cleanup: prepare "update_handler" for WITHOUT OVERLAPS

Elena Stepanova added a comment - 2020-06-09 22:22 MDEV-22847 is marked as a duplicate of this one. Some notes: Representation of the failure without UPDATE is not identical to the initially reported one. The reported one is a debug assertion which happens in the mixed combination (apparently because only UPDATE makes mixed replication switch to RBR, while INSERT doesn't). The reduced version of the test case without UPDATE causes SIGSEGV in the row combination of the test, and it affects both debug and non-debug builds. Here is the stack trace from it: #3 <signal handler called> #4 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:286 #5 0x0000560680c94788 in handler::check_duplicate_long_entry_key (this=0x7f22cc038e00, new_rec=0x7f22cc035898 "\370\001", key_no=0) at /data/src/10.5/sql/handler.cc:6645 #6 0x0000560680c94fd1 in handler::check_duplicate_long_entries (this=0x7f22cc038e00, new_rec=0x7f22cc035898 "\370\001") at /data/src/10.5/sql/handler.cc:6726 #7 0x0000560680c95dc9 in handler::ha_write_row (this=0x7f22cc038e00, buf=0x7f22cc035898 "\370\001") at /data/src/10.5/sql/handler.cc:6996 #8 0x0000560680df8af2 in Rows_log_event::write_row (this=0x7f22cc033f28, rgi=0x7f22cc000a90, overwrite=false) at /data/src/10.5/sql/log_event_server.cc:7260 #9 0x0000560680df9747 in Write_rows_log_event::do_exec_row (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event_server.cc:7480 #10 0x0000560680df33d5 in Rows_log_event::do_apply_event (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event_server.cc:5650 #11 0x0000560680829feb in Log_event::apply_event (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event.h:1496 #12 0x000056068081ca58 in apply_event_and_update_pos_apply (ev=0x7f22cc033f28, thd=0x7f22cc001598, rgi=0x7f22cc000a90, reason=0) at /data/src/10.5/sql/slave.cc:4003 #13 0x000056068081d03e in apply_event_and_update_pos (ev=0x7f22cc033f28, thd=0x7f22cc001598, rgi=0x7f22cc000a90) at /data/src/10.5/sql/slave.cc:4165 #14 0x000056068081d990 in exec_relay_log_event (thd=0x7f22cc001598, rli=0x56068406f6d8, serial_rgi=0x7f22cc000a90) at /data/src/10.5/sql/slave.cc:4482 #15 0x00005606808212fd in handle_slave_sql (arg=0x56068406da10) at /data/src/10.5/sql/slave.cc:5659 #16 0x0000560681002b56 in pfs_spawn_thread (arg=0x7f22e01face8) at /data/src/10.5/storage/perfschema/pfs.cc:2201 #17 0x00007f23150824a4 in start_thread (arg=0x7f230c312700) at pthread_create.c:456 #18 0x00007f23131b6d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 both variations are reproducible with InnoDB as well, with the same test cases. I don't know what happened when you tried, please double-check. it fails on 10.4 after completing MDEV-22747 because one of the commits you are backporting introduced the failure. This one: commit 0515577d128318e1b62511846d88d0c56226168d Author: Sergei Golubchik Date: Thu Mar 5 19:19:57 2020 +0100 cleanup: prepare "update_handler" for WITHOUT OVERLAPS

Elena Stepanova made changes - 2020-06-09 22:23

Link

This issue duplicates ~~MDEV-22847~~ [ ~~MDEV-22847~~ ]

Elena Stepanova made changes - 2020-06-09 22:24

Component/s		Replication [ 10100 ]
Labels		regression
Priority	Major [ 3 ]	Blocker [ 1 ]

Elena Stepanova made changes - 2020-06-09 22:41

Component/s

Server [ 13907 ]

Sergei Golubchik made changes - 2020-06-10 12:27

Assignee	Sergei Golubchik [ serg ]	Sachin Setiya [ sachin.setiya.007 ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Sachin Setiya (Inactive) made changes - 2020-06-11 05:13

Fix Version/s		10.5.4 [ 24264 ]
Fix Version/s	10.5 [ 23123 ]
Resolution		Fixed [ 1 ]
Status	Stalled [ 10000 ]	Closed [ 6 ]

Sergei Golubchik made changes - 2021-12-06 21:51

Workflow

MariaDB v3 [ 109174 ]

MariaDB v4 [ 157861 ]

People

Assignee:: Sachin Setiya (Inactive)

Reporter:: Alice Sherepa

Votes:: 0 Vote for this issue

Watchers:: 4 Start watching this issue

Dates

Created:: 2020-05-26 14:00

Updated:: 2023-09-07 12:18

Resolved:: 2020-06-11 05:13

Git Integration

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

MariaDB Server

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration