Re: glibc updarte 2.31 to 2.38

On 9/19/24 13:56, Paul Foerster wrote:
>> On 19 Sep 2024, at 17:14, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Maybe. We don't really track glibc changes, so I can't say for sure,
>> but it might be advisable to reindex indexes on string columns.

> Advisable is a word I undfortunately can't do much with. We have
> terabytes and terabytes of data in hundreds of databases each having
> potentially hundreds of columns that are candidates. Just reindexing
> and taking down applications during that time is not an option in a
> 24x7 high availability environment.

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).

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

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.

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com