S3 Storage engine (MDEV-17841)

[MDEV-19585] Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed upon SELECT from S3 table with concurrent BACKUP stage Created: 2019-05-24  Updated: 2023-05-16  Resolved: 2019-06-27

Status: Closed
Project: MariaDB Server
Component/s: Backup, Storage Engine - S3
Affects Version/s: 10.5
Fix Version/s: 10.4.7, 10.5.0

Type: Technical task Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-19416 Test S3 Storage engine Closed

 Description   

Note: it fails for me every time, but it's still a concurrent and hence non-deterministic test case. Run with --repeat=N if it doesn't fail right away.

CREATE TABLE t1 (a INT);
ALTER TABLE t1 ENGINE=S3;
 
--connect (con1,localhost,root,,test)
BACKUP STAGE START;
 
--connection default
--send
SELECT * FROM t1;
 
--connection con1
BACKUP STAGE BLOCK_COMMIT;
 
# Cleanup
BACKUP STAGE END;
--disconnect con1
--connection default
--reap
DROP TABLE t1;

10.5 ebfe8c4e

mysqld: /data/src/10.5/sql/sql_error.cc:335: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
190524 15:44:35 [ERROR] mysqld got signal 6 ;
 
#6  0x00007fedcaf36e67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x5615e72998e8 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=file@entry=0x5615e7299828 "/data/src/10.5/sql/sql_error.cc", line=line@entry=335, function=function@entry=0x5615e7299c00 <Diagnostics_area::set_ok_status(unsigned long long, unsigned long long, char const*)::__PRETTY_FUNCTION__> "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at assert.c:92
#7  0x00007fedcaf36f12 in __GI___assert_fail (assertion=0x5615e72998e8 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x5615e7299828 "/data/src/10.5/sql/sql_error.cc", line=335, function=0x5615e7299c00 <Diagnostics_area::set_ok_status(unsigned long long, unsigned long long, char const*)::__PRETTY_FUNCTION__> "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at assert.c:101
#8  0x00005615e6649fb1 in Diagnostics_area::set_ok_status (this=0x7feda00064c8, affected_rows=0, last_insert_id=0, message=0x0) at /data/src/10.5/sql/sql_error.cc:335
#9  0x00005615e65f1ca6 in my_ok (thd=0x7feda0000b10, affected_rows_arg=0, id=0, message=0x0) at /data/src/10.5/sql/sql_class.h:4993
#10 0x00005615e66a01ab in mysql_execute_command (thd=0x7feda0000b10) at /data/src/10.5/sql/sql_parse.cc:5285
#11 0x00005615e66aa08b in mysql_parse (thd=0x7feda0000b10, rawbuf=0x7feda0011fc8 "BACKUP STAGE BLOCK_COMMIT", length=25, parser_state=0x7fedbd4df180, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8152
#12 0x00005615e6695715 in dispatch_command (command=COM_QUERY, thd=0x7feda0000b10, packet=0x7feda0008591 "BACKUP STAGE BLOCK_COMMIT", packet_length=25, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1829
#13 0x00005615e6693ed5 in do_command (thd=0x7feda0000b10) at /data/src/10.5/sql/sql_parse.cc:1362
#14 0x00005615e680be5b in do_handle_one_connection (connect=0x5615e9b78e80, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1413
#15 0x00005615e680bb9f in handle_one_connection (arg=0x5615e9b78e80) at /data/src/10.5/sql/sql_connect.cc:1309
#16 0x00005615e713f953 in pfs_spawn_thread (arg=0x5615e9b78ad0) at /data/src/10.5/storage/perfschema/pfs.cc:1862
#17 0x00007fedcd3124a4 in start_thread (arg=0x7fedbd4e0700) at pthread_create.c:456
#18 0x00007fedcaff3d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97



 Comments   
Comment by Michael Widenius [ 2019-06-26 ]

The problem was two fault:

  • flush_tables() wrongly gave errors when failing to open read only tables
  • backup_block_ddl() didn't properly ignores errors from flush_tables()

The fix will be pushed into 10.4 and the test case for this will be pushed in 10.5 as the test involves S3 tables.

Comment by Michael Widenius [ 2019-06-27 ]

Fix pushed into 10.4. Test case will be pushed into 10.5

Generated at Thu Feb 08 08:52:49 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.