Rıza

How you got here is worth understanding so it does not repeat: the replica is running on a host with a different operating system version from the source.

That is extremely common when building a new replica on newer hardware or a newer base image, and it is one of the standard traps in database migration. The data files came from a machine with one locale library and are now being read by a machine with another.

Two ways to avoid it in future:

Match the operating system version between primary and replicas, and upgrade them together deliberately rather than incidentally.

Use a collation provider that versions independently of the operating system, which recent PostgreSQL versions support. That decouples sort order from whatever the host happens to ship and is the more durable answer for anything long-lived.

The other thing that makes a true per-role view hard: inheritance.

Roles can be members of other roles, and by default a member inherits the privileges of the roles it belongs to. So listing direct grants to a role understates what it can actually do — the effective set includes everything granted to every role it inherits from, transitively.

If what you want is "what can this role actually do", the access privilege inquiry functions are the right tool. They answer the effective question directly for a given role and object, taking inheritance into account, rather than reporting what was granted.

That is a genuinely different query and usually the one people mean when they ask this.

The same reasoning shows up in other databases with different numbers, which is a nice illustration that these limits are engineering consequences rather than arbitrary choices.

PostgreSQL uses 8 kilobyte pages too by default and handles oversized values by compressing and moving them to a separate storage area automatically, which is a different solution to the same constraint.

Once you know that rows live in fixed-size pages, a lot of otherwise inexplicable limits across different systems stop being surprising.