From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Paul Foerster <paul(dot)foerster(at)gmail(dot)com> |
Cc: | pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: glibc updarte 2.31 to 2.38 |
Date: | 2024-09-19 17:07:16 |
Message-ID: | 7e5c776d-58e0-4e97-8b65-a7076ac503d4@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 9/19/24 11:14, Tom Lane wrote:
> Paul Foerster <paul(dot)foerster(at)gmail(dot)com> writes:
>> we have SLES 15.5 which has glibc 2.31. Our admin told us that
>> he's about to install the SLES 15.6 update which contains glibc
>> 2.38.
>> 2) Does the glibc update have any impact?
> 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.
Every glibc major version change potentially impacts the sorting of some
strings, which would require reindexing. Whether your actual data trips
into any of these changes is another matter.
You could check by doing something equivalent to this on every
collatable column with an index built on it, in every table:
8<-----------
WITH t(s) AS (SELECT <collatable_col> FROM <some_table> ORDER BY 1)
SELECT md5(string_agg(t.s, NULL)) FROM t;
8<-----------
Check the before and after glibc upgrade result -- if it is the same,
you are good to go. If not, rebuild the index before *any* DML is done
to the table.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2024-09-19 17:12:11 | Re: glibc updarte 2.31 to 2.38 |
Previous Message | Tom Lane | 2024-09-19 15:14:34 | Re: glibc updarte 2.31 to 2.38 |