[MDEV-24267] Data truncated for column 'VARIABLE_VALUE' at row 1 Created: 2020-11-23  Updated: 2022-06-01

Status: Confirmed
Project: MariaDB Server
Component/s: Information Schema
Affects Version/s: 10.4.17
Fix Version/s: 10.4, 10.5

Type: Bug Priority: Minor
Reporter: Muhammad Irfan Assignee: Sergei Golubchik
Resolution: Unresolved Votes: 2
Labels: None


 Description   

Global variables table from information_schema database variable_value column varchar(2048) doesn't seems to be enough and generates warning "Data truncated for column 'VARIABLE_VALUE'".

CREATE TEMPORARY TABLE `GLOBAL_VARIABLES` (
 
`VARIABLE_NAME` varchar(64) NOT NULL DEFAULT '',
 
`VARIABLE_VALUE` varchar(2048) NOT NULL DEFAULT ''

For instance:

ssl_cipher  ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
 
ssl_key /etc/my.cnf.d/keys/redacted_server.key

And wsrep_provider_options can't hold it and value truncated for ssl_cipher variable.

MariaDB [(none)]> SHOW VARIABLES LIKE 'wsrep_provider_options'\G
 
*************************** 1. row ***************************
 
Variable_name: wsrep_provider_options
 
 Value: base_dir = /var/lib/mysql/; base_host = redacted; base_port = 4567; cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; evs.auto_evict = 0; evs.causal_keepalive_period = PT1S; evs.debug_log_mask = 0x1; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.info_log_mask = 0; evs.install_timeout = PT7.5S; evs.join_retrans_period = PT1S; evs.keepalive_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.use_aggregate = true; evs.user_send_window = 2; evs.version = 1; evs.view_forget_timeout = P1D; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = galera.cache; gcache.page_size = 128M; gcache.recover = yes; gcache.size = 4G; gcomm.thread_prio = ; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.listen_addr = ssl://0.0.0.0:4567; gmcast.mcast_addr = ; gmcast.mcast_ttl = 1; gmcast.peer_timeout = PT3S; gmcast.segment = 10; gmcast.time_wait = PT5S; gmcast.version = 0; ist.recv_addr = redacted; pc.announce_timeout = PT3S; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false; pc.linger = PT20S; pc.npvo = false; pc.recovery = true; pc.version = 0; pc.wait_prim = true; pc.wait_prim_timeout = PT30S; pc.weight = 1; protonet.backend = asio; protonet.version = 0; repl.causal_read_timeout = PT30S; repl.commit_order = 3; repl.key_format = FLAT8; repl.max_ws_size = 2147483647; repl.proto_max = 10; socket.checksum = 2; socket.recv_buf_size = auto; socket.send_buf_size = auto; socket.ssl = YES; socket.ssl_ca = /etc/pki/tls/certs/redacted.crt; socket.ssl_cert = /etc/pki/tls/certs/redacted.crt; socket.ssl_cipher = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA
 
1 row in set, 1 warning (0.001 sec)
 
 
 
MariaDB [(none)]> SHOW WARNINGS\G
 
*************************** 1. row ***************************
 
 Level: Warning
 
 Code: 1265
 
Message: Data truncated for column 'VARIABLE_VALUE' at row 1
 
1 row in set (0.000 sec)



 Comments   
Comment by Elena Stepanova [ 2020-11-24 ]

Assigning to serg for a decision on the matter.

Comment by Imre Jonk [ 2022-03-18 ]

Hi, this issue affects me as well. My Galera cluster nodes log this warning quite often.
Does anyone know of a workaround? Can I safely grow the column size?

Comment by Sergei Golubchik [ 2022-03-23 ]

This warning simply means that the value of wsrep_provider_options is longer than 2048 characters. Nothing is broken, it's safe to ignore it. No, you cannot change the column size of a built-in information_schema table, it's hard-coded.

Comment by Imre Jonk [ 2022-03-23 ]

Thanks Sergei. I said in my previous comment that my Galera nodes log this warning, but it turns out to be my application. My application logs all warnings from the database connector, so I'm just going to filter out these specific log messages using a feature of the logging library.

By the way this issue affects users of MariaDB 10.3 (RHEL 8 build) as well.

Comment by Michal Schorm [ 2022-05-31 ]

Is there still anything you want to get fixed / changed, or are you both fine with with the explanation Sergei gave you, Muhammad Irfan, Imre Jonk ?

Comment by Imre Jonk [ 2022-06-01 ]

Hi Michal, thanks for checking up on this. I'm mostly happy with Sergei's explanation. I (or actually my colleague) didn't have time yet to reconfigure the logging library we use so that this warning can be suppressed in our application's logging output. We don't expect this to be a problem however.

Regarding your comment in Red Hat Bugzilla on whether this is a bug or not: I have a feeling that this is open to interpretation. Sergei says that nothing is broken, and that is true. You say that you believe it is an expected warning message which I guess makes sense as well. I initially opened the Red Hat bug because I believed this to be a bug, with the definition of a bug being "the software displayed some unexpected behavior". But I understand now that this behavior is actually expected.

Maybe it is an idea to document (in official documentation) that this warning message is to be expected? If it isn't already of course (I couldn't find it).

I am not a MariaDB developer, so I hardly feel qualified to simply say "this is a bug" or "this is not a bug", nor do I want to persuade anyone to "fix" something. I just hope that the feedback that I provide here can in some way be useful to the MariaDB developers.

Generated at Thu Feb 08 09:28:41 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.