[MCOL-5624] bugs in columnstore.cnf Created: 2023-12-10  Updated: 2024-02-01

Status: Open
Project: MariaDB ColumnStore
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Sergei Golubchik Assignee: Leonid Fedorov
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Problem/Incident
is caused by MCOL-5519 Overhaul Columnstore.cnf Closed
Relates

 Description   

MCOL-5519 added three lines to columnstore.cnf

collation_server = utf8_general_ci
character_set_server = utf8
 
columnstore_use_import_for_batchinsert = ON

All three are problematic:

  • first two change default server character set for the whole server. That is, a user was a working server installation. Installs columnstore — and suddenly the server uses a different default character set. Uninstalls columnstore — columnstore.cnf is removed (on Fedora, for example), and again, suddenly the charset is different. This is a major gotcha, plugin's cnf file should only change plugin's configuration. Fix: remove these lines.
  • last line only works when columnstore is installed. But on Debian cnf files are not removed when the plugin is uninstalled. Meaning, after uninstalling columnstore the server will fail to start. Fix: use the loose- prefix.


 Comments   
Comment by Leonid Fedorov [ 2023-12-11 ]

This config file exists for one ES release at least, I don't see the reason, why its called blocker. Setting this utf option was Todd's decision, took a time or update the infrastructure, and instantly removing this from config file will break our CI.

Comment by Leonid Fedorov [ 2023-12-11 ]

serg what is -loose prefix BTW?

Comment by Sergei Golubchik [ 2023-12-11 ]

https://mariadb.com/kb/en/mariadbd-options/#-loose-

Comment by Leonid Fedorov [ 2023-12-11 ]

Ok, we'll modify the last option is it's possible, about the first two it should be discussed. Nevertheless the possible customer scenarios described in the issue are synthetic and a bit far-fectched. This is not even critical issue IMHO

Generated at Thu Feb 08 02:59:15 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.