Search Postgresql Archives

Re: glibc updarte 2.31 to 2.38

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Joe,

> On 19 Sep 2024, at 20:09, Joe Conway <mail@xxxxxxxxxxxxx> wrote:
> 
> 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).

Yes, I know that.

> For more examples about that see https://joeconway.com/presentations/glibc-SCaLE21x-2024.pdf

A very interesting PDF. Thanks very much.

> 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.

I'm not a developer. I have one machine which is equivalent to all other servers except that it has gcc, make and some other things for me to build PostgreSQL. I can't make the admins run a rpm on all servers. I can obviously put a library into the /path/2/postgres/software/lib64 directory but not into the system.

Also, my build server does not have internet access. So things like git clone would be an additional show stopper. Unfortunately, I'm pretty limited.

Cheers,
Paul







[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux