public inbox for [email protected]
help / color / mirror / Atom feedglibc updarte 2.31 to 2.38
7+ messages / 4 participants
[nested] [flat]
* glibc updarte 2.31 to 2.38
@ 2024-09-19 14:37 Paul Foerster <[email protected]>
2024-09-19 15:14 ` Re: glibc updarte 2.31 to 2.38 Tom Lane <[email protected]>
2024-09-19 17:43 ` Re: glibc updarte 2.31 to 2.38 Peter J. Holzer <[email protected]>
0 siblings, 2 replies; 7+ messages in thread
From: Paul Foerster @ 2024-09-19 14:37 UTC (permalink / raw)
To: pgsql-general list <[email protected]>
Hi,
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.
I have built our PostgreSQL software from source on SLES 15.5, because we have some special requirements which the packages cannot fulfill. So I have questions:
1) Do I have to build it again on 15.6?
2) Does the glibc update have any impact? I recall having to have everything reindexed when the 2.28 update came due to major locale changes, but I didn't have to do it since then.
3) Where and how can I find out if it is necessary to reindex? And how can I find out what indexes would be affected.
I'd really appreciate your comments. Thanks very much in advance.
Paul
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: glibc updarte 2.31 to 2.38
2024-09-19 14:37 glibc updarte 2.31 to 2.38 Paul Foerster <[email protected]>
@ 2024-09-19 15:14 ` Tom Lane <[email protected]>
2024-09-19 17:07 ` Re: glibc updarte 2.31 to 2.38 Joe Conway <[email protected]>
2024-09-19 17:56 ` Re: glibc updarte 2.31 to 2.38 Paul Foerster <[email protected]>
1 sibling, 2 replies; 7+ messages in thread
From: Tom Lane @ 2024-09-19 15:14 UTC (permalink / raw)
To: Paul Foerster <[email protected]>; +Cc: pgsql-general list <[email protected]>
Paul Foerster <[email protected]> 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.
> I have built our PostgreSQL software from source on SLES 15.5, because we have some special requirements which the packages cannot fulfill. So I have questions:
> 1) Do I have to build it again on 15.6?
No, I wouldn't expect that to be necessary.
> 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.
regards, tom lane
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: glibc updarte 2.31 to 2.38
2024-09-19 14:37 glibc updarte 2.31 to 2.38 Paul Foerster <[email protected]>
2024-09-19 15:14 ` Re: glibc updarte 2.31 to 2.38 Tom Lane <[email protected]>
@ 2024-09-19 17:07 ` Joe Conway <[email protected]>
1 sibling, 0 replies; 7+ messages in thread
From: Joe Conway @ 2024-09-19 17:07 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Paul Foerster <[email protected]>; +Cc: pgsql-general list <[email protected]>
On 9/19/24 11:14, Tom Lane wrote:
> Paul Foerster <[email protected]> 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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: glibc updarte 2.31 to 2.38
2024-09-19 14:37 glibc updarte 2.31 to 2.38 Paul Foerster <[email protected]>
2024-09-19 15:14 ` Re: glibc updarte 2.31 to 2.38 Tom Lane <[email protected]>
@ 2024-09-19 17:56 ` Paul Foerster <[email protected]>
2024-09-19 18:09 ` Re: glibc updarte 2.31 to 2.38 Joe Conway <[email protected]>
1 sibling, 1 reply; 7+ messages in thread
From: Paul Foerster @ 2024-09-19 17:56 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-general list <[email protected]>
Hi Tom,
> On 19 Sep 2024, at 17:14, Tom Lane <[email protected]> wrote:
>
> No, I wouldn't expect that to be necessary.
I was hoping one of the pros would say that. 🤣
> 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.
Cheer,
Paul
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: glibc updarte 2.31 to 2.38
2024-09-19 14:37 glibc updarte 2.31 to 2.38 Paul Foerster <[email protected]>
2024-09-19 15:14 ` Re: glibc updarte 2.31 to 2.38 Tom Lane <[email protected]>
2024-09-19 17:56 ` Re: glibc updarte 2.31 to 2.38 Paul Foerster <[email protected]>
@ 2024-09-19 18:09 ` Joe Conway <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Joe Conway @ 2024-09-19 18:09 UTC (permalink / raw)
To: Paul Foerster <[email protected]>; Tom Lane <[email protected]>; +Cc: pgsql-general list <[email protected]>
On 9/19/24 13:56, Paul Foerster wrote:
>> On 19 Sep 2024, at 17:14, Tom Lane <[email protected]> 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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: glibc updarte 2.31 to 2.38
2024-09-19 14:37 glibc updarte 2.31 to 2.38 Paul Foerster <[email protected]>
@ 2024-09-19 17:43 ` Peter J. Holzer <[email protected]>
2024-09-19 18:12 ` Re: glibc updarte 2.31 to 2.38 Paul Foerster <[email protected]>
1 sibling, 1 reply; 7+ messages in thread
From: Peter J. Holzer @ 2024-09-19 17:43 UTC (permalink / raw)
To: [email protected]
On 2024-09-19 16:37:41 +0200, Paul Foerster wrote:
> 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.
>
> I have built our PostgreSQL software from source on SLES 15.5, because
> we have some special requirements which the packages cannot fulfill.
> So I have questions:
>
> 1) Do I have to build it again on 15.6?
>
> 2) Does the glibc update have any impact? I recall having to have
> everything reindexed when the 2.28 update came due to major locale
> changes, but I didn't have to do it since then.
>
> 3) Where and how can I find out if it is necessary to reindex?
I wrote a small script[1] which prints all unicode code points and a few
selected[2] longer strings in order. If you run that before and after
the upgrade and the output doesn't change, you are probably be fine.
(It checks only the default collation, though: If you have indexes using
a different collation you would have to modify the script accordingly.)
If there are differences, closer inspection might show that the changes
don't affect you. But I would reindex all indexes on text (etc.) columns
just to be sure.
hp
[1] https://git.hjp.at:3000/hjp/pgcollate
[2] The selection is highly subjective and totally unscientific.
Additions are welcome.
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | [email protected] | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: glibc updarte 2.31 to 2.38
2024-09-19 14:37 glibc updarte 2.31 to 2.38 Paul Foerster <[email protected]>
2024-09-19 17:43 ` Re: glibc updarte 2.31 to 2.38 Peter J. Holzer <[email protected]>
@ 2024-09-19 18:12 ` Paul Foerster <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Paul Foerster @ 2024-09-19 18:12 UTC (permalink / raw)
To: Peter J. Holzer <[email protected]>; +Cc: [email protected]
Hi Peter,
> On 19 Sep 2024, at 19:43, Peter J. Holzer <[email protected]> wrote:
>
> I wrote a small script[1] which prints all unicode code points and a few
> selected[2] longer strings in order. If you run that before and after
> the upgrade and the output doesn't change, you are probably be fine.
> (It checks only the default collation, though: If you have indexes using
> a different collation you would have to modify the script accordingly.)
>
> If there are differences, closer inspection might show that the changes
> don't affect you. But I would reindex all indexes on text (etc.) columns
> just to be sure.
>
> hp
>
> [1] https://git.hjp.at:3000/hjp/pgcollate
> [2] The selection is highly subjective and totally unscientific.
> Additions are welcome.
I'm not a Python specialist but I take it that the script need psycopg2, which we probably don't have. So I'd have to build some sort of venv around that like I had to do to get Patroni working on our systems.
Well, we'll see.
Thanks for this script.
Cheers,
Paul
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2024-09-19 18:12 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-09-19 14:37 glibc updarte 2.31 to 2.38 Paul Foerster <[email protected]>
2024-09-19 15:14 ` Tom Lane <[email protected]>
2024-09-19 17:07 ` Joe Conway <[email protected]>
2024-09-19 17:56 ` Paul Foerster <[email protected]>
2024-09-19 18:09 ` Joe Conway <[email protected]>
2024-09-19 17:43 ` Peter J. Holzer <[email protected]>
2024-09-19 18:12 ` Paul Foerster <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox