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 1vBzs4-007jTU-1r for pgsql-general@arkaria.postgresql.org; Thu, 23 Oct 2025 18:17:07 +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 1vBzs2-00AtaM-Vm for pgsql-general@arkaria.postgresql.org; Thu, 23 Oct 2025 18:17:06 +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 1vBzs2-00AtaE-LH for pgsql-general@lists.postgresql.org; Thu, 23 Oct 2025 18:17:05 +0000 Received: from ns7.gunduz.org ([165.232.104.158]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vBzrz-003r0S-1q for pgsql-general@lists.postgresql.org; Thu, 23 Oct 2025 18:17:05 +0000 Received: from ehlo.thunderbird.net (unknown [148.252.129.188]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ns7.gunduz.org (Postfix) with ESMTPSA id 7A49F30001FD; Thu, 23 Oct 2025 18:17:01 +0000 (UTC) Date: Thu, 23 Oct 2025 21:16:59 +0300 From: =?ISO-8859-1?Q?Devrim_G=FCnd=FCz?= To: pgsql-general@lists.postgresql.org, Bala M Subject: =?US-ASCII?Q?Re=3A_Index_corruption_issue_after_migration_from_RHE?= =?US-ASCII?Q?L_7_to_RHEL_9_=28PostgreSQL_11_streaming_replication=29?= User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----0UUHWEFHGZ233K3J1YIZ4A7JPBEBO5 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------0UUHWEFHGZ233K3J1YIZ4A7JPBEBO5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, This happens because of the glibc version differrence between RHEL X and R= HEL Y=2E At this point you either have to rebuild all indexes (sorry!) or r= edo the upgrade via logical replication (if it works for your app's behavio= ur) Devrim On 22 October 2025 12:03:06 EEST, Bala M wro= te: >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 replicatio= n* >(base backup method)=2E > >After bringing up the standby on RHEL 9, we observed that certain tables >are not returning results when queries use indexed scans=2E Upon >investigation, the following check confirms index corruption: > >The same indexes work fine on the RHEL 7 (primary) side=2E However, on >the RHEL 9 replica, queries that rely on this index return zero >records=2E >Rebuilding the indexes fixed the issue temporarily but we have many >indexes and our DB size is more than 10TB=2E > >*Environment details:* > > - > > PostgreSQL Version: 11=2E15 > - > > OS on primary: RHEL 7=2E9 > - > > OS on standby: RHEL 9=2E6 > - > > Replication Type: Streaming replication (initialized using pg_baseback= up) > - > > Data Directory initialized from RHEL 7 base backup > >*Issue Summary:* > > - > > Indexes appear and are the same size as per prod on standby after bas= e > backup restore=2E > - > > We are able to read the data from the tables without index scans on > standy by RHEL 9=2E > - > > No filesystem or WAL errors observed in logs=2E > >Could this be related to OS-level binary or page layout differences betwe= en >RHEL 7 and RHEL 9 for PostgreSQL 11 binaries? >Any insights or recommended actions would be greatly appreciated=2E > > >Thanks & Regards, >*krishna=2E* ------0UUHWEFHGZ233K3J1YIZ4A7JPBEBO5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

This happens because = of the glibc version differrence between RHEL X and RHEL Y=2E At this point= you either have to rebuild all indexes (sorry!) or redo the upgrade via lo= gical replication (if it works for your app's behaviour)


Devrim<= /div>

On 22 October 202= 5 12:03:06 EEST, Bala M <krishna=2Epgdba@gmail=2Ecom> 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)=2E

After bringing up the standby on RHEL 9, we observed that certain table= s are not returning results when queries use indexed scans=2E Upon investig= ation, the following check confirms index corruption:

The same indexes work fine on the RHEL 7 (primary) side=2E Howev=
er, on the RHEL 9 replica, queries that rely on this index return zero reco=
rds=2E 
Rebuilding the i=
ndexes  fixed=
 the issue temporarily but we have many indexes  and our DB size is more th=
an 10TB=2E

Environment details:

  • PostgreSQL Version: 11=2E15

  • OS on primary: RHEL 7=2E9

  • OS on standby: RHEL 9=2E6

  • Replication Type: Streaming replication (initialized using pg_bas= ebackup)

  • 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=2E

  • We are able to read  the data from the tables without index scans = on standy by RHEL 9=2E

  • No filesystem or WAL errors observed in logs=2E

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

=

Thanks & Regards,
krishna=2E


------0UUHWEFHGZ233K3J1YIZ4A7JPBEBO5--