Re: glibc updarte 2.31 to 2.38

Hi Joe,

> On 19 Sep 2024, at 20:09, Joe Conway <mail(at)joeconway(dot)com> wrote:
>
> See my thread-adjacent email, but suffice to say that if there are collation differences that do affect your tables/data, and you allow any inserts or updates, you may wind up with corrupted data (e.g. duplicate data in your otherwise unique indexes/primary keys).

Yes, I know that.

> For more examples about that see https://joeconway.com/presentations/glibc-SCaLE21x-2024.pdf

A very interesting PDF. Thanks very much.

> An potential alternative for you (discussed at the end of that presentation) would be to create a new branch based on your original SLES 15.5 glibc RPM equivalent to this:
>
> https://github.com/awslabs/compat-collation-for-glibc/tree/2.17-326.el7
>
> The is likely a non trivial amount of work involved (the port from the AL2 rpm to the RHEL7 rpm took me the better part of a couple of days), but once done your collation is frozen to the specific version you had on 15.5.

I'm not a developer. I have one machine which is equivalent to all other servers except that it has gcc, make and some other things for me to build PostgreSQL. I can't make the admins run a rpm on all servers. I can obviously put a library into the /path/2/postgres/software/lib64 directory but not into the system.

Also, my build server does not have internet access. So things like git clone would be an additional show stopper. Unfortunately, I'm pretty limited.

Cheers,
Paul