Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\))
Subject: Re: glibc updarte 2.31 to 2.38
From: Paul Foerster <paul.foerster@gmail.com>
In-Reply-To: <7e5c776d-58e0-4e97-8b65-a7076ac503d4@joeconway.com>
Date: Thu, 19 Sep 2024 20:07:55 +0200
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 pgsql-general list <pgsql-general@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <10C568C1-5985-4434-9A73-9ED6C5B64FB1@gmail.com>
References: <B927CE6F-0A36-4237-BD4D-75CD609F3E89@gmail.com>
 <1991352.1726758874@sss.pgh.pa.us>
 <7e5c776d-58e0-4e97-8b65-a7076ac503d4@joeconway.com>
To: Joe Conway <mail@joeconway.com>
Archived-At: <https://www.postgresql.org/message-id/10C568C1-5985-4434-9A73-9ED6C5B64FB1%40gmail.com>
Precedence: bulk

Hi Joe,

> On 19 Sep 2024, at 19:07, Joe Conway <mail@joeconway.com> wrote:
>=20
> 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.
>=20
> You could check by doing something equivalent to this on every =
collatable column with an index built on it, in every table:
>=20
> 8<-----------
> WITH t(s) AS (SELECT <collatable_col> FROM <some_table> ORDER BY 1)
> SELECT md5(string_agg(t.s, NULL)) FROM t;
> 8<-----------
>=20
> 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.

I like the neatness of this one. I think about how to implement this on =
hundreds of of databases with hundreds of columns. That'll be a =
challenge, but at least it's a start.

Thanks very much for this one.

Cheers,
Paul=