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
