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@sss.pgh.pa.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