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 1vBWTy-00057i-Ug for pgsql-general@arkaria.postgresql.org; Wed, 22 Oct 2025 10:54:18 +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 1vBWTx-00FM5j-OV for pgsql-general@arkaria.postgresql.org; Wed, 22 Oct 2025 10:54:16 +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 1vBUkZ-00Ekul-8i for pgsql-general@lists.postgresql.org; Wed, 22 Oct 2025 09:03:18 +0000 Received: from mail-io1-xd36.google.com ([2607:f8b0:4864:20::d36]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vBUkW-0038Cd-27 for pgsql-general@lists.postgresql.org; Wed, 22 Oct 2025 09:03:17 +0000 Received: by mail-io1-xd36.google.com with SMTP id ca18e2360f4ac-93e847a443fso446628439f.0 for ; Wed, 22 Oct 2025 02:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761123795; x=1761728595; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=LbkH5wxG5t9CAO6J+othFb4XyP8T5nOvJwDKy3/rpos=; b=gkXrsRz5tccPLCNFCmS1KcOUkOGx6VnpWNWOypDBt3yPColsKLpcLc1KNoXB+Kaxxo J1rwxGiNCDVX+MxYyQ2P7NR90TeQtuDPlRvxhDj435fDL77oeaZJCdAxATAqr9vjZFp/ UaMx8D0kEPA5vdgr3NmuMbimUWyRlPb53pvA81Ns+o759j7fhRowNs3lc5vAkYgPGi8o 3n8yIopWwtvuRstMdW3XW8r+IjjRVl0S7zi9JRJ+p36k+RKN4egTnRBqA2iM6ptRjtvK 5iQ+nlewl3VdYi33xSZs2vzPmACVVpC/SB2MS+nxkinWf5E7mniFf3jLTJhsgxbDDpqG kxtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761123795; x=1761728595; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=LbkH5wxG5t9CAO6J+othFb4XyP8T5nOvJwDKy3/rpos=; b=BpzwJbcU5DWUXANrBBGktwIpwmQq6Yqf4SHaTz2deacx5MSrTolyacYKp1DNZhO2HR OPH1OUYpZWmAby52xr7uFsykq0bf4QdMsFe5knvQ/4PbzKk69hk/4b/5Hma/6sVtFahP WlhJCLW127BwdcvMp8qNryphPRJysN3EgOaWXYlgDsmMdxd7G5cTckFoM0fO1CpeGPew aVj5ZeeXo+2k/sW9K6ILo5vftrTq6fuEJp7+dL0ZKo+QwgEcbayM7lNGbIDBvLzmSViP gLa1DF15cY0kgqEOhzU0D/EtCixJyVYZDujon5P9CYuu52wL//5Aqia4qOgevb49yqkR Dulw== X-Gm-Message-State: AOJu0YzLnCbZTu5Igt0bNKzd8HprLFbxL9+f83tAo9kNesiq7v1kBE4B G5sCFqddyd50a9CovRAuNjwFXnL38lgpS5BqV/r0a/V8YNVUQoYt6kxAPb5pI2tvzqO6W6UNkWT 3FIUlDt/OegfJhjsWvuSQIT1fAjRmPL/ph8fO X-Gm-Gg: ASbGncsELoI+Ug6an7AN0Je3mJWtBL7KlyfmQOavwEQGE1T2A1XhPVhxM2npnEREKoU TXU+pso3TRA1tWpbk+66Gjj1eTM9a21yoJuF077veFGsOchWInjOlJl6+vowzAZwRjorNVLp/G1 jmmxeGvWm1DtU1e6dEgJyifXCzusipHZpmN7K2Q8bqlhIcv/YSEQw3KkDk9aL3vXQByN/ZxWv3e W5NFmGV4de88NUBc8A7toljisrV2dDvqwxQoopy7E2gy3Nx7lPI9K6HV18LISp7mugBXwZ1 X-Google-Smtp-Source: AGHT+IF7OtKjOUyP9rUqfqNvEg1yjdWoMN3nIhikVR7//Y1TCbAuFIt2JafIx+XXK4KGG0XeGII1R7Nq26rgpWFpYpw= X-Received: by 2002:a05:6e02:158b:b0:42b:2a51:f50a with SMTP id e9e14a558f8ab-430c532bf2dmr300273155ab.31.1761123795543; Wed, 22 Oct 2025 02:03:15 -0700 (PDT) MIME-Version: 1.0 From: Bala M Date: Wed, 22 Oct 2025 14:33:06 +0530 X-Gm-Features: AS18NWCvOuH9ojfuiHShAoL1B8BL8tUYelb9o80681kdZ73JWICnZaokHzkm0pg Message-ID: Subject: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication) To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000003d2a800641bb9623" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003d2a800641bb9623 Content-Type: text/plain; charset="UTF-8" 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.* --0000000000003d2a800641bb9623 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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 RHEL 7 (primary) side. However,= on the RHEL 9 replica, queries that rely on this index return zero records= .
<= span style=3D"font-family:Arial,Helvetica,sans-serif">Rebuilding the indexe= s fixed the = issue temporarily but we have many indexes and our DB size is more than 10= TB.

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.


--0000000000003d2a800641bb9623--