Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u4FAw-009nKe-A7 for pgsql-general@arkaria.postgresql.org; Mon, 14 Apr 2025 08:28:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u4FAu-00Fe0s-9m for pgsql-general@arkaria.postgresql.org; Mon, 14 Apr 2025 08:28:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u4FAt-00Fe0j-VD for pgsql-general@lists.postgresql.org; Mon, 14 Apr 2025 08:28:16 +0000 Received: from mout02.posteo.de ([185.67.36.66]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u4FAs-000G2E-0O for pgsql-general@lists.postgresql.org; Mon, 14 Apr 2025 08:28:16 +0000 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 4BD39240101 for ; Mon, 14 Apr 2025 10:28:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1744619293; bh=39w7QTXWGkUD0XlNQzZ+WRDuBniAoVp4zM3LFDMJuuU=; h=Message-ID:Subject:From:To:Date:Content-Type: Content-Transfer-Encoding:MIME-Version:From; b=X4Mg2LeGOFvnH28SdD+7wj+y63JFznCs145nldpLhRGa2nm8R7gYUWB0LyiGTpQsh /+H79FFszQqwDtbGzSt7kAaaFqjEct9v15WSNfq5pozyioji+WuzDd3/iXL0tTQbtV mQeSkqQ6qvh6KT8wnsJSUZLgjONzZ/poo7llD/iZxCNagQz2+huxF3HUC7ZbtxA8cO xvGVR501M84jBYPHuSMDToWB41I4KiGrxmozqzT1AhZL2/9mExZgbpK2naNRs3rFMn FJu+0RS9TZpixkTRrM29AyY2Ap/X4clcFQPFfR09+BREZOYDOzLldsKM3F5Qj9B6DS H8rWYdZ0Uy0TQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZbgR05nryz9rxF for ; Mon, 14 Apr 2025 10:28:12 +0200 (CEST) Message-ID: <8ed41c50ba6c5322296b869e497c1b5573853b54.camel@posteo.de> Subject: ICU Collations and Collation Updates From: Thomas Michael Engelke To: pgsql-general@lists.postgresql.org Date: Mon, 14 Apr 2025 08:28:12 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Good morning, long time reader, first time writer. Where I currently work my colleagues used libc collations before I arrived. While using libc collations, they stumbled upon the collation update problem after SLES updates (15.4 to 15.5) (collation version difference for database and operating system) (paraphrased, don't have the english message at the hand). For an easy solution I suggested to switch to ICU collations. While documenting the problem for older systems I realized that I did not know enough about the problem to document why ICU collations would solve this problem. After reading https://www.postgresql.org/docs/17/collation.html this is how I understand it: When initdb creates a cluster the OS available collations are copied to the database as database objects, listable using select * from pg_collation; Now, an OS collation update as part of the OS update will change the collations available on the OS level, but not the collations that the database uses. Is my understanding correct then in that this way the database collations never change, unless a manual intervention reinitialises the collations and reindexes the database (or appropriate indexes)? How does that process compare to other RDBMS? Are regular collation updates deemed unnecessary for long running database installations? Or do you people have maintenance workflows that incorporate regular collation updates to the databases? Thanks, Thomas