commit 4af1cf5a09bcf5f199e4135db14bb6123987c102
author Leonid <63977577+leborchuk@users.noreply.github.com> Wed Feb 04 16:54:52 2026 +0300
committer GitHub <noreply@github.com> Wed Feb 04 16:54:52 2026 +0300
tree 2d408b353d6630d53669bdc133c30f28fed41035
parent 2cc5674ea6e3a5cc85ff9101daf08b8dee5d533e

Movable DataBase Locales for Cloudberry (#1363)

* Movable DataBase Locales for Cloudberry

We inherited this issue from PostgreSQL.

PostgreSQL uses glibc to sort strings. In version glibc=2.28, collations
broke down badly (in general, there are no guarantees when updating glibc).
Changing collations breaks indexes. Similarly, a cluster with different
collations also behaves unpredictably.

What and when something has changed in glibc can be found
on https://github.com/ardentperf/glibc-unicode-sorting
Also there is special postgresql-wiki https://wiki.postgresql.org/wiki/Locale_data_changes
And you tube video https://www.youtube.com/watch?v=0E6O-V8Jato

In short, the issue can be seen through the use of bash:

( echo "1-1"; echo "11" ) | LC_COLLATE=en_US.UTF-8 sort

gives the different results in ubunru 18.04 and 22.04.

There is no way to solve the problem other than by not changing the symbol order.
We freeze symbol order and use it instead of glibc.

Here the solution https://github.com/postgredients/mdb-locales.

In this PR I have added PostgreSQL patch that replaces all glibc
locale-related calls with a calls to an external libary. It activates
using new configure parameter --with-mdblocales, which is off by
default.

Using custom locales needs libmdblocales1 package and mdb-locales
package with symbol table.

Build needs libmdblocales-dev package with headers.

Fixing the symbol order is necessary for OS upgrade. For example Ubuntu 22.04 EOL is April 2027, Rocky 8 Active Support ended May 2024, and Security support ends in 2029.

We use Movable DataBase Locales in Greenplum 6 and all our PostgreSQL installations (starting with PostgreSQL 12). This patch is adopted patch version from our internal PostgreSQL 14 fork.

* mdb_admin role

This patch introcudes new pseudo-pre-defined role "mdb_admin".

Introduces 2 new function:
extern bool mdb_admin_allow_bypass_owner_checks(Oid userId,  Oid ownerId);
extern void check_mdb_admin_is_member_of_role(Oid member, Oid role);

To check mdb admin belongship and role-to-role ownership transfer
correctness.

Our mdb_admin ACL model is the following:
 * Any roles user or/and roles can be granted with mdb_admin
 * mdb_admin memeber can tranfser ownershup of relations,
   namespaces and functions to other roles, if target role in neither:
   superuser, pg_read_server_files, pg_write_server_files nor
   pg_execute_server_program.

* mdb_superuser role

This patch introcudes new pseudo-pre-defined role "mdb_superuser".

Role is capable of:

GRANT/REVOKE any set of priviledges to/from any object in database.
Has power of pg_database_owner in any database, including:
DROP any object in database (except system catalog and stuff)

Role is NOT capable of:

Create database, role, extension or alter other roles with such
priviledges.

Transfer ownership to /pass has_priv of roles:

PG_READ_ALL_DATA
PG_WRITE_ALL_DATA
PG_EXECUTE_SERVER_PROGRAM
PG_READ_SERVER_FILES
PG_WRITE_SERVER_FILES
PG_DATABASE_OWNER

Allow mdb_superuser to alter objects and grant ACl to
objects, owner by pg_database_owner. Also, when acl check,
allow mdb_supersuer use pg_database_owner role power to pass check

* Extend multixact SLRU

The issue here is the same as for the PG, good detail description I found in Nikolay blog post https://v2.postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful  
See also the history of original PG patches in https://commitfest.postgresql.org/patch/2627/  We could get all those fixes after rebasing to PG18, but for now, we need to adjust SLRU structure sizes.

---------
Co-authored-by: usernamedt <usernamedt@yandex-team.com>
Co-authored-by: reshke <reshkekirill@gmail.com>