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 1vBXzX-000PCV-4S for pgsql-general@arkaria.postgresql.org; Wed, 22 Oct 2025 12:30:58 +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 1vBXzU-00G4vY-Ih for pgsql-general@arkaria.postgresql.org; Wed, 22 Oct 2025 12:30:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vBXzT-00G4ua-Vy for pgsql-general@lists.postgresql.org; Wed, 22 Oct 2025 12:30:55 +0000 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vBXzQ-0039qy-05 for pgsql-general@lists.postgresql.org; Wed, 22 Oct 2025 12:30:53 +0000 Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-b3c2c748bc8so840828566b.2 for ; Wed, 22 Oct 2025 05:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=simply-italian-co-uk.20230601.gappssmtp.com; s=20230601; t=1761136249; x=1761741049; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gy2dtjFt8juyxBAw2s3NZzoyH8eESt6nMs4HoSVbX6s=; b=QVlDHUh6jnFIkf6JTXSPlJdyW9aZIPw/fu/M2Mo94qbCDnIHeEKRmLChyrBu2V/5in +scMs4eRKjMfzgwzeIVpNWi1Q3PZiD9zkyh2j2Bl6nAitH4fXMHZUx+KdHppbpcHL4p6 6pnPJfo+trik07ZYRiD9WJ6Gi34E6p/IyNrFknDuCLE5OTzLyPIW0LI/Kzdy/xHAQM1m R5+qm+WsagbllS/AOAVmA9F2v51/kjxHsdrMDljpWiebMfpmcGM0ye0xIBciMTfAx/6t iNZkykAN8GEWos6BIE9F6unH5Q6Apx4KDY+L4aNJA/cLHxhlMs9tCz570fjyhpuiezEV sQ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761136249; x=1761741049; h=cc: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=gy2dtjFt8juyxBAw2s3NZzoyH8eESt6nMs4HoSVbX6s=; b=ANi1tgrGjZsGWWSibj25EjQJ+R3gl0wykgDh52l/aVIZ+ec4YYcdVaXoSyqG/VzEJI FNLYMXfqy/NSyEYFdqJjiKnbaH28CkBRa2PtIBqrMKCoIhQzqRUV9PMkeQ46K267MsUv fjTtr5ZdJyHRqttGETzxK45W5/qLaogLzPqQCw3fwEse2Vm6jrtZ/ud+U7d9N32fLvXy RuGbUGvGabvKJzX6f8oY1EoTqrO6QxpKktLLG0fmy3A0xfI4EZWk+K9b594cLztJTtUg ewU2Ll3UURlrhqpagiG+5RrekrM2V2D3emnfGx5F17t6UwChPUz9xnPVOTOirg+39sWe ZsRQ== X-Gm-Message-State: AOJu0YwsMDugKpuj8VySqCEI6Z5419F3TtkQUXg+dhG3WfyAyHu8uBn4 0ecM0Vvnw0LlEa4rldzlpE9C9H53Vn6K+BZiCGDj5Asj3OjqhLfwaWOSk32NpkU1DgosFp8p8zp ukGuAppfCz5Vmvrp8qeCT9eAlUfBs9Numx73mAjsLAw== X-Gm-Gg: ASbGncv13z6Wy515j0uJ4FUL1soyaB9nTZ6sqTCgnO6IAFtc4tvgcBbLYv/06zRCZcg XrbKPeSx3su2Bz8uWDnq+Qe9Di9nOBWFZ4uACavLdpdDzoaooms0MeSJ50lVRnnarYUhJvhEeBE f88qqFnBAAi/s6i+sZ+IGRWjEl/Xk9JPECQM1irGF9xSP88BTv+WIE/x6nOPnc3nAPe+Iv4a9MC 6CMjDrkEfbYG9q1MKYtRi54xiwEB7yLJJvsBpfTnsQEX0xeZloJ/n/zfqyyqvWVWqIK2EHB X-Google-Smtp-Source: AGHT+IEz7/HbdKLTCx32dtSs/3u4C5XpKXyiZCpuXlStmODBEK5uneKDp6t7gnfwkMcGOKpYvGKOtDpxNpD16NjfpPY= X-Received: by 2002:a17:907:3ccb:b0:aff:fe6:78f0 with SMTP id a640c23a62f3a-b64764e4b6bmr2584691466b.54.1761136248797; Wed, 22 Oct 2025 05:30:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chris Wilson Date: Wed, 22 Oct 2025 13:30:12 +0100 X-Gm-Features: AS18NWA9twihc80SSnKugY8tTJD_lXdqXpPXCbsirlpTRpfK0G2l0se2JkcVQ6c Message-ID: Subject: Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication) To: Bala M Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000082cdf20641be7cb6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000082cdf20641be7cb6 Content-Type: text/plain; charset="UTF-8" Hi Krishna, This might be due to the upgrade in glibc between RHEL7 and RHEL8, which includes updated collations that change sort orders and thus invalidate existing indexes, forcing them to be rebuilt (on a RHEL>7 system) if they contain any values which sort differently under the new collation than the old one. More details can be found here, including a query to identify affected indexes: https://wiki.postgresql.org/wiki/Locale_data_changes [RHEL] *Version 8 uses the new locale data*. Therefore, caution will be > necessary when upgrading." Thanks, Chris. On Wed, 22 Oct 2025 at 11:53, Bala M wrote: > Hi Team, > > We are facing an issue related to index corruption after migrating our > PostgreSQL 11 setup from *RHEL 7* to *RHEL 9* using *streaming > replication* (base backup method). > > After bringing up the standby on RHEL 9, we observed that certain tables > are not returning results when queries use indexed scans. Upon > investigation, the following check confirms index corruption: > > The same indexes work fine on the RHEL 7 (primary) side. However, on the RHEL 9 replica, queries that rely on this index return zero records. > Rebuilding the indexes fixed the issue temporarily but we have many indexes and our DB size is more than 10TB. > > *Environment details:* > > - > > PostgreSQL Version: 11.15 > - > > OS on primary: RHEL 7.9 > - > > OS on standby: RHEL 9.6 > - > > Replication Type: Streaming replication (initialized using > pg_basebackup) > - > > Data Directory initialized from RHEL 7 base backup > > *Issue Summary:* > > - > > Indexes appear and are the same size as per prod on standby after > base backup restore. > - > > We are able to read the data from the tables without index scans on > standy by RHEL 9. > - > > No filesystem or WAL errors observed in logs. > > Could this be related to OS-level binary or page layout differences > between RHEL 7 and RHEL 9 for PostgreSQL 11 binaries? > Any insights or recommended actions would be greatly appreciated. > > > Thanks & Regards, > *krishna.* > > --00000000000082cdf20641be7cb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Krishna,

This might be du= e to the upgrade in glibc between RHEL7 and RHEL8, which includes updated c= ollations that change sort orders and thus invalidate existing indexes, for= cing them to be rebuilt (on a RHEL>7 system) if they contain any values = which sort differently under the new collation than the old one.
=
More details can be found here, including a query to identif= y affected indexes:=C2=A0https://wiki.postgresql.org/wiki/Locale_data_changes

[RHEL]= =C2=A0Version 8 uses the new locale data. Therefore, caution will be= necessary when upgrading."

Thanks, Ch= ris.

On Wed, 22 Oct 2025 at 11:53, Bala M <krishna.pgdba@gmail.com> wr= ote:

Hi Team,

We are facing an issue related to index corruption after migrating our P= ostgreSQL 11 setup from RHEL 7 to RHEL 9 = using streaming replication (base backup method).

After bringing up the standby on RHEL 9, we observed that certain tables= are not returning results when queries use indexed scans. Upon investigati= on, the following check confirms index corruption:

The same indexes work fine on the R= HEL 7 (primary) side. However, on the RHEL 9 replica, queries that rely on = this index return zero records.
Rebuilding the indexes <= span style=3D"font-family:Arial,Helvetica,sans-serif"> fixed the issue temp= orarily but we have many indexes and our DB size is more than 10TB.=

Environment details:

  • PostgreSQL Version: 11.15

  • OS on primary: RHEL 7.9

  • OS on standby: RHEL 9.6

  • Replication Type: Streaming replication (initialized using pg_base= backup)

  • Data Directory initialized from RHEL 7 base backup

Issue Summary:

  • Indexes appear and are the same=C2=A0size as per prod=C2=A0 on standby a= fter base backup restore.

  • We are able to read=C2=A0 the data from the tables without index scans o= n standy by RHEL 9.

  • No filesystem or WAL errors observed in logs.

Could this be related to OS-level binary or page layout differences betw= een RHEL 7 and RHEL 9 for PostgreSQL 11 binaries?
Any insights or recommended actions would be greatly appreciated.

Thanks & Regards,
krishna.


--00000000000082cdf20641be7cb6--