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 1v3aDT-000fqm-Qd for pgsql-admin@arkaria.postgresql.org; Tue, 30 Sep 2025 13:16:27 +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 1v3aDR-009vw1-QF for pgsql-admin@arkaria.postgresql.org; Tue, 30 Sep 2025 13:16:26 +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 1v3aDR-009vvt-Cy for pgsql-admin@lists.postgresql.org; Tue, 30 Sep 2025 13:16:26 +0000 Received: from mail-ot1-x330.google.com ([2607:f8b0:4864:20::330]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v3aDP-000uI9-1i for pgsql-admin@postgresql.org; Tue, 30 Sep 2025 13:16:25 +0000 Received: by mail-ot1-x330.google.com with SMTP id 46e09a7af769-7bd8909c682so131586a34.3 for ; Tue, 30 Sep 2025 06:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759238181; x=1759842981; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=dVdtJabhPyoeXWKPGamlRubgoiHCNHOi9yqrllP/vXg=; b=aDsDNv77/whiGxYTAlRBCV3Uop4hcOj3AQc6DpgeGp60gQFpgp2ZMX4WtITVX9NHBU KJj4shQJQr7M7TIrtkz6+N6B1Fy4Mo9C4uq0lD/gL7FcUfJlUhK+N0TYEexHO7kP7msA 8SgX+gFQemta1ctjn1HuKh+4KpLOXY0J+tvETMRcmz6SqBMJ/5kUgJPYzt6XTV5a/c3U f0BCjghx3fEKDW2muKsogaCdhswIjgeDsSHTPYaUxvRLj06Y6UWMUJzaRClGYfNyQk5D uH1S4uO4zKEsUo+KJOuBrrtBqiIGI0raybfdxZd/s7NKKSFW0v6Fa4crPgfEoBApRl/V smkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759238181; x=1759842981; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dVdtJabhPyoeXWKPGamlRubgoiHCNHOi9yqrllP/vXg=; b=MOXnwfzu7MBT1GfXeTqj9paEa2cv+VlKgpDi8SgawJQylFI2QsR6Q7eDyGDLRCiuu1 8DiMb0I/9C4p5+nYSAN+RQ+0cUm40Fw6l/MrU9kuQYdxKH6cjYyj1Vog4EKT+4sQeR3M DWP3farZWS8eCut2NQA/eOCusXosmV26QLLsh6XgE20MSxGSem4k89bdvWeJJyBSYlHm uY7FI+ZUguw606FCUzWk90zWiAZv/Fo66ITBqoz0ETW/c2L6cFyC1d09PkAUL2uvTrBc GSRDqiAC5EYj1z1KlZWFPVIVUZeZxD1WqvxNLXqeosX/bpcTf8axoGOEQhpTKxJcj0xP B1+w== X-Gm-Message-State: AOJu0YwxVR10VPn79Om3AjdlCJdqlNwgM12Kp52kAdF5nZsvcCN5QFIp Jr7jIn0g8oVijyxdB13Gy93BrWUUStdUJdJamU4xSgrT3VH/HaxG8TXoHaB6mHlaHEolXAdl7FP yYnKbJoJodFNaiYeWNxYLeTs416kX48TWXw== X-Gm-Gg: ASbGnctlInaC7yu5dHw7t9KlmwFE7hsGHvuVN626Ywpd9fJAnrpLu4YHKJ+48chI0O2 42CXl3aU7bcyd5Z0OPhHaVsNVODmHgX5otF/c3DNScHqTDQmh68IJqNS+wjVh56GTe/Eih1DRJE 5/Xwd0YTtygKR35DHX7SP5sJBHYseuFLZS0cV+SSFUbs3rXADzZh9vObjgnEVxtc9Df7l5a6Pjg dEZTWaLHwd8keuMkdNq5YwbC8a0s8EZ X-Google-Smtp-Source: AGHT+IECT4Wx/uwcEs9UvMoaMHCXMMhQ7MX/zKzLf1CnF4EHoW/DeVOzYg6TXuo+sNhs/T0jR3dFuebe63V3M3A8Ff4= X-Received: by 2002:a05:6808:1492:b0:43d:6b7b:2469 with SMTP id 5614622812f47-43f4cbb4b3bmr9982607b6e.4.1759238181543; Tue, 30 Sep 2025 06:16:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Tue, 30 Sep 2025 09:16:10 -0400 X-Gm-Features: AS18NWDPnYfGFgL7OTynN8vWexmEPK7HIVCrei-k6ap70ZmHkvhZ_FuD-P7PqdY Message-ID: Subject: Re: Necessary actions after an OS upgrade To: "pgsql-admin@postgresql.org" Content-Type: multipart/alternative; boundary="000000000000e2e5490640048e6d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e2e5490640048e6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2025 at 5:50=E2=80=AFAM Zwettler Markus (OIZ) < markus.zwettler@zuerich.ch> wrote: > We use Crunchy Postgres for Kubernetes (CPK). With CPK 5.8, there will be > an OS upgrade from UBI8 to UBI9 images. As described in both the Crunchy > and Postgres documentation, conflicts due to collation version mismatches > following an OS upgrade can lead to incorrect queries. > > > > > https://access.crunchydata.com/documentation/postgres-operator/latest/tut= orials/cluster-management/update-cluster#changing-base-images > > > https://www.postgresql.org/docs/current/sql-altercollation.html#SQL-ALTER= COLLATION-NOTES > > > > According to the documentation, we plan to perform a =E2=80=9Creindex dat= abase=E2=80=9D > I would only rebuild text indices. Most indices are (probably) INTEGER or BIGINT, so this would save you a lot of time > and a =E2=80=9Calter database refresh collation version=E2=80=9D immediat= ely after the > upgrade. > > > > > > Is there anything else to consider? I'm wondering if this is sufficient. > > > > What about materialized views, > > (text) function-based indexes > That would be caught by REINDEX ALL, no? > , and extensions? Couldn't problems arise here as well? None of the > documentation addresses this. Am I thinking about this incorrectly? > > > > Ideally, I would like to have a precise list of everything that needs to > be considered and done afterwards. > > --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000e2e5490640048e6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 30, 2025 at 5:50=E2=80=AFAM Z= wettler Markus (OIZ) <mark= us.zwettler@zuerich.ch> wrote:

We use= Crunchy Postgres for Kubernetes (CPK). With CPK 5.8, there will be an OS u= pgrade from UBI8 to UBI9 images. As described in both the Crunchy and Postg= res documentation, conflicts due to collation version mismatches following an OS upgrade can = lead to incorrect queries.

=C2=A0

https://access.crunchydata.com/documentation/postgres-operator/lat= est/tutorials/cluster-management/update-cluster#changing-base-images=

https://www.postgresql.org/docs/curre= nt/sql-altercollation.html#SQL-ALTERCOLLATION-NOTES

=C2=A0

Accord= ing to the documentation, we plan to perform a =E2=80=9Creindex database=E2= =80=9D


I woul= d only rebuild text indices.=C2=A0 Most indices are (probably) INTEGER or B= IGINT, so this would save you a lot of time
=C2=A0

and a =E2=80=9Calter database refresh collat= ion version=E2=80=9D immediately after the upgrade.

=C2=A0

=C2=A0

Is the= re anything else to consider? I'm wondering if this is sufficient.

=C2=A0

What a= bout materialized views,

=C2= =A0

(text) function-based ind= exes


That woul= d be caught by REINDEX ALL, no?
=C2=A0

, and extensions? Couldn't problems arise here as w= ell? None of the documentation addresses this. Am I thinking about this incorrectly?

=C2=A0

Ideall= y, I would like to have a precise list of everything that needs to be consi= dered and done afterwards.


--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000e2e5490640048e6d--