May 2025 - developers - lists.mariadb.org

Windows line endings in MariaDB test result files?
by Otto Kekäläinen 14 May '25

14 May '25

Hi, While importing 11.4.6 into Debian I ran into issues with git and quilt failing to convert text files properly between Unix and Windows line endings. Thus asking are Windows CRLF necessary in the new mysql-test/main/mysql-interactive.result test? commit e5147c8140450f28505a227159d2feba37dd1c39 Author: Sergei Golubchik <serg(a)mariadb.org> Date: Tue Jan 30 16:39:28 2024 +0100 regression introduced by MDEV-14448 diff --git a/mysql-test/main/mysql-interactive.result b/mysql-test/main/mysql-interactive.result new file mode 100644 index 00000000000..a18c018b932 --- /dev/null +++ b/mysql-test/main/mysql-interactive.result @@ -0,0 +1,24 @@ +# +# regression introduced by MDEV-14448 +# +delimiter $^M +select 1;^M +$^M +Welcome to the MariaDB monitor. Commands end with ; or \g.^M +Your MariaDB connection id is X^M +Server version: Y^M +Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.^M +^M +Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.^M +^M +MariaDB [(none)]> delimiter $^M +MariaDB [(none)]> select 1;^M + -> $^M ++---+^M +| 1 |^M ++---+^M +| 1 |^M ++---+^M +1 row in set^M +^M +MariaDB [(none)]> All the other files with Windows line endings seem to be have them intentionally: ± find . -type f -exec file {} \; | grep -i "CRLF" ./storage/connect/mysql-test/connect/std_data/emp.txt: ASCII text, with CRLF line terminators ./storage/connect/mysql-test/connect/std_data/boyswin.txt: ASCII text, with CRLF line terminators ./storage/connect/mysql-test/connect/std_data/expenses.txt: ASCII text, with CRLF line terminators ./storage/connect/mysql-test/connect/r/xml.result: HTML document, UTF-8 Unicode text, with CRLF, LF line terminators ./mysql-test/std_data/loadxml2.dat: XML 1.0 document, ASCII text, with very long lines, with CRLF, LF line terminators ./mysql-test/main/loadxml.result: ASCII text, with CRLF, LF line terminators ./mysql-test/main/func_regexp_pcre.result: UTF-8 Unicode text, with very long lines, with CRLF, CR, LF line terminators ./mysql-test/main/mysql-interactive.result: ASCII text, with CRLF, LF line terminators ./mysql-test/main/mysql_binary_mode.result: ASCII text, with CRLF, LF line terminators ./extra/wolfssl/wolfssl/certs/test/smime-test-canon.p7s: MIME entity, ASCII text, with CRLF, CR line terminators ./extra/wolfssl/wolfssl/wolfssl.rc: C source, Little-endian UTF-16 Unicode text, with CRLF line terminators

2 4

MariaDB near 50% in WordPress usage stats
by Otto Kekäläinen 13 May '25

13 May '25

Hi all, Glad to see that MariaDB has now surpassed MySQL in WordPress usage stats at https://wordpress.org/about/stats/ Version Usage MySQL 8.0 20.77% MariaDB 10.6 19.88% MariaDB 10.11 18.60% MySQL 5.7 17.78% MySQL 5.5 7.03% MariaDB 10.5 6.77% MariaDB 10.3 2.74% MySQL 5.6 1.99% MariaDB 11.4 1.27% MariaDB 10.4 1.07% MariaDB 5.5 0.46% MariaDB 10.1 0.43% MariaDB 10.2 0.32% MySQL 5.1 0.17% MySQL 8.4 0.14% I haven't verified this myself, but I heard that MySQL 8.4 deprecated SQL_CALC_FOUND_ROWS which is heavily used in the WordPress code base, and thus the MySQL 8.4 adoption is nearly zero. Good reminder to have collaboration and joint testing with some of the largest open source projects to avoid accidentally having a new MariaDB version being incompatible with them..

2 2

pthread_yield() vs std::this_thread::yield()
by Sergey Vojtovich 09 May '25

09 May '25

Monty and I had an argument recently regarding pthread_yield() and std::this_thread::yield() usage. I do want to make this discussion public, so that we can pick either approach, get it documented and make sure everybody is aware of reasoning and decision. Probably even add a bb check that wouldn't allow unwanted function calls to pass. Lets try to keep this discussion focused on std::this_thread::yield() and avoid discussing other C++11 features. Since I'm biased towards std::this_thread::yield() I'd let Monty elaborate his concerns and explain why he prefers pthread_yield(). But generally it comes to compatibility and portability. My position is: pthread_yield() should be removed in favour of std::this_thread::yield(). Benefits: 1. Must be available to all current MariaDB versions. C++11 is a must since 2018. 2. Compatibility and portability, which we don't have to care about. 3. I have no performance concerns after analysing how it is implemented by clang and gcc. 4. Goes inline with "MDEV-35461 - Remove redundant checks for standard library functions" 5. Standard things looks more community-friendly, e.g. why should MSVC developers care about POSIX threads? Currently pthread_yield() can be defined to: 1. SwitchToThread() - Win32 (Wlad, 2009) MSVC seems to support std::this_thread::yield() since 2015: https://learn.microsoft.com/en-us/cpp/standard-library/thread-functions?vie… 2. thr_yield() - Solaris (Serg, 2009) Oracle Developer Studio 12.6 supports std::this_thread::yield() since 2017: https://docs.oracle.com/cd/E77782_01/html/E77789/bkabe.html#OSSCPgnyio 3. pthread_yield_np() - OS X (Serg, 2009) XCode is based on clang, which supports std::this_thread::yield() since 2013. sched_yield() - default (Serg, 2009) pthread_yield() - deprecated since 2021 (Serg, 2009) Possible concerns: 1. Compatibility with recent platforms. C++11 is widely available, thread models seem to be well supported. InnoDB uses std::this_thread_yield() since 2021. 2. Compatibility with older (ancient?) platforms. We're way off into C++11 since 2018. Making recent MariaDB compile on such platforms is probably going to be a heavy effort. If we do really want to have these platforms supported, they must be present in buildbot. 3. Performance impact of std::this_thread::yield(). See below. In many cases it is just a wrapper around functions like sched_yield. clang: libcxx/include/__thread/this_thread.h:inline _LIBCPP_HIDE_FROM_ABI void yield() _NOEXCEPT { __libcpp_thread_yield(); } libcxx/src/support/win32/thread_win32.cpp:void __libcpp_thread_yield() { SwitchToThread(); } libcxx/include/__thread/support/pthread.h:inline _LIBCPP_HIDE_FROM_ABI void __libcpp_thread_yield() { sched_yield(); } gcc additionally supports VxWorks: yield() noexcept { #if defined _GLIBCXX_HAS_GTHREADS && defined _GLIBCXX_USE_SCHED_YIELD __gthread_yield(); #endif } int __gthread_yield (void) { return taskDelay (0); } __GTHREAD_INLINE int __gthread_yield (void) { return __gthrw_(sched_yield) (); } Regards, Sergey

3 2

Commit ff4209fa0d1c66952bc9f00587f525314464e7be not merged on main?
by Otto Kekäläinen 08 May '25

08 May '25

Hi! I was updating the patch https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/d… in Debian when importing MariaDB 11.4.6, and I noticed that the upstream commit that changes the same lines in https://github.com/MariaDB/server/commit/ff4209fa0d1c66952bc9f00587f5253144… only landed on MariaDB '10.11' and '11.4' branch, but never on 'main' or '11.8'. Could it be that 'main' has had zero merges from older branches since April 3? Or was there maybe some mistake and one merge was overlooked and it wasn't properly applied on all newer maintained branches?

2 2