Debian Patches
Status for mariadb/1:10.11.6-0+deb12u1
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0025-Change-the-default-optimization-from-O3-to-O2-in-mys.patch | Change the default optimization from -O3 to -O2 in mysql_release.cmake BUILD_CONFIG profile | Ondrej Sury <ondrej@debian.org> | yes | 2017-11-22 | ||
| rocksdb-kfreebsd.patch | # Merged in RocksDB 6.13.fb, but not updated into MariaDB yet Description: Upstream has merged this but we still need to wait for it to be included in a RocksDB release and imported into MariaDB and then into Debian. |
Andrew Kryczka <andrewkr@fb.com> | yes | upstream | 2020-06-16 | |
| env-perl-usr-bin-perl.patch | Fix perl path in scripts Fix Lintian issue https://lintian.debian.org/tags/incorrect-path-for-interpreter.html . Upstream will never accept this patch, see https://github.com/MariaDB/server/pull/1718 |
Otto Keklinen <otto@debian.org> | yes | https://patch-diff.githubusercontent.com/raw/MariaDB/server/pull/1718.patch | 2020-12-20 | |
| fix-spelling-rocksdb.patch | Fix various spelling errors still found in code Two upstream PRs remain that have been merged, but not imported on MariaDB yet. | Otto Keklinen <otto@debian.org> | yes | https://patch-diff.githubusercontent.com/raw/facebook/rocksdb/pull/9653.patch | 2022-03-02 | |
| fix-reproducible-builds-rocksdb.patch | Make RocksDB build reproducible The RocksDB binary included a string with the build timestamp: > rocksdb_build_git_date:@2021-05-2316:04:38@ As this changes from build to build, it makes the builds unreproducible. Simply removing it solves the issue. This temporary fix can be removed when a proper fix already done in upstream lands in MariaDB when the RocksDB submodule is updated to a newer release. |
Otto Keklinen <otto@kekalainen.net> | yes | upstream | https://github.com/facebook/rocksdb/commit/0a9a05ae12943b1529ef1eabbca5ce5a71c986bf | |
| mroonga-mrn-lib-dirs-path-reproducible-build.patch | [PATCH] cmake: add support for reproducible buildS . We should use relative path not absolute path. We can use target without breaking reproducibility. |
Sutou Kouhei <kou@clear-code.com> | not-needed | upstream | https://github.com/mroonga/mroonga/issues/298#issuecomment-1030815927 | 2022-02-05 |
| 2129-new-script-wsrep-sst-backup-fixes.patch | [PATCH] Properly introduce wsrep_sst_backup script in project packaging The script wsrep_sst_backup was introduced on MariaDB 10.3 in commit 9b2fa2a. The new script was automatically included in RPM packages but not in Debian packages (which started to fail on waring about stray file). Include wsrep_sst_backup in the mariadb-server-10.{3..8} package, and also include a stub man page so that packaging of a new script is complete. |
Otto Keklinen <otto@kekalainen.net> | yes | https://patch-diff.githubusercontent.com/raw/MariaDB/server/pull/2129.patch | 2022-05-22 | |
| 2541-fix-stack-overflow-in-pinbox-allocator.patch | [PATCH] Fix a stack overflow in pinbox allocator MariaDB supports a "wait-free concurrent allocator based on pinning addresses". In `lf_pinbox_real_free()` it tries to sort the pinned addresses for better performance to use binary search during "real free". `alloca()` was used to allocate stack memory and copy addresses. To prevent a stack overflow when allocating the stack memory the function checks if there's enough stack space. However, the available stack size was calculated inaccurately which eventually caused database crash due to stack overflow. The crash was seen on MariaDB 10.6.11 but the same code defect exists on all MariaDB versions. A similar issue happened previously and the fix in fc2c1e43 was to add a `ALLOCA_SAFETY_MARGIN` which is 8192 bytes. However, that safety margin is not enough during high connection workloads. MySQL also had a similar issue and the fix https://github.com/mysql/mysql-server/commit/b086fda was to remove the use of `alloca` and replace qsort approach by a linear scan through all pointers (pins) owned by each thread. This commit is mostly the same as it is the only way to solve this issue as: 1. Frame sizes in different architecture can be different. 2. Number of active (non-null) pinned addresses varies, so the frame size for the recursive sorting function `msort_with_tmp` is also hard to predict. 3. Allocating big memory blocks in stack doesn't seem to be a very good practice. For further details see the mentioned commit in MySQL and the inline comments. All new code of the whole pull request, including one or several files that are either new files or modified ones, are contributed under the BSD-new license. I am contributing on behalf of my employer Amazon Web Services, Inc. |
Hugo Wen <wenhug@amazon.com> | yes | https://patch-diff.githubusercontent.com/raw/MariaDB/server/pull/2541.patch | 2023-03-11 |
All known versions for source package 'mariadb'
- 1:11.4.5-2~exp1 (experimental)
- 1:11.4.5-1 (trixie, sid)
- 1:10.11.11-0+deb12u1 (bookworm-proposed-updates)
- 1:10.11.6-0+deb12u1 (bookworm)