MIME-Version: 1.0
References: <AS2PR05MB1075477BA334D4DA262AD75BFEF16A@AS2PR05MB10754.eurprd05.prod.outlook.com>
 <fd548bde-54d3-426a-a2b6-058750cfb554@aklaver.com> <AS2PR05MB1075432E74AF2FA975B02519AEF61A@AS2PR05MB10754.eurprd05.prod.outlook.com>
 <b1fec029-b8fb-4177-a01a-9457e813ce68@aklaver.com> <AS2PR05MB107546BEE7B8092148A0B51A0EF61A@AS2PR05MB10754.eurprd05.prod.outlook.com>
 <25b5291f-a3d3-4655-a3d3-57f28b70ec5a@aklaver.com> <AS2PR05MB107546C1B04FC4B3CCF32E60CEF7DA@AS2PR05MB10754.eurprd05.prod.outlook.com>
 <78328b08-249e-4251-8a10-b5dac183442a@aklaver.com> <DB5PR05MB107646FFE78759D1D5431F802EF7AA@DB5PR05MB10764.eurprd05.prod.outlook.com>
 <0868c260-9812-4629-b32d-026c1fe6089f@aklaver.com> <AS2PR05MB1075476F648651C8CC02D8048EF79A@AS2PR05MB10754.eurprd05.prod.outlook.com>
 <CAKAnmmLsxdt51sp-w0JxMi0haGXHFKD2pXURfOSOa5iVzjni4w@mail.gmail.com>
 <7d455186-0cba-4fd5-9f9e-7051627b3ae3@aklaver.com> <CAKAnmmJzw9TeOd=_VtJ430_AhS+asfRLuOg=mgL0yT_K+7X-yQ@mail.gmail.com>
 <2016a784-0644-4932-a0f1-3613c2521c78@aklaver.com>
In-Reply-To: <2016a784-0644-4932-a0f1-3613c2521c78@aklaver.com>
From: Greg Sabino Mullane <htamfids@gmail.com>
Date: Tue, 10 Mar 2026 10:15:01 -0400
Message-ID: <CAKAnmmJogm0T4vF5nvhzK=GbfAcPhsLtKR_yRn-neMQP7S2_YQ@mail.gmail.com>
Subject: Re: Index (primary key) corrupt?
To: Adrian Klaver <adrian.klaver@aklaver.com>
Cc: Wim Rouquart <wim.rouquart@kbc.be>, 
	"pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000004ccbf0064cac2739"
Archived-At: <https://www.postgresql.org/message-id/CAKAnmmJogm0T4vF5nvhzK%3DGbfAcPhsLtKR_yRn-neMQP7S2_YQ%40mail.gmail.com>
Precedence: bulk

--0000000000004ccbf0064cac2739
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 9, 2026 at 3:53=E2=80=AFPM Adrian Klaver <adrian.klaver@aklaver=
.com>
wrote:

> Yeah, but the indrelid did not change after the the REINDEX.
>

Agreed, but none of this makes sense. pg_dump grabs pks via a bulk pg_index
scan based on table oids, so I wanted to rule out some problem there.

I'm chalking this one up to user error, not database corruption, as the OP
has not actually shown us the output of how they are determining the
missing index, and then how the reindex fixes it (although I appreciate the
pg_index query results). To put another way, user error is a much more
likely explanation than anything else given the lack of specific data.

Cheers,
Greg

--0000000000004ccbf0064cac2739
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Mar 9, 2026 at 3:53=E2=80=AFPM Ad=
rian Klaver &lt;<a href=3D"mailto:adrian.klaver@aklaver.com">adrian.klaver@=
aklaver.com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_conta=
iner"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">Yeah, but the indre=
lid did not change after the the REINDEX.<br></blockquote><div><br></div><d=
iv>Agreed, but none of this makes sense. pg_dump grabs pks via a bulk pg_in=
dex scan based on table oids, so I wanted to rule out some problem there.</=
div><div><br></div><div>I&#39;m chalking this one up to user error, not dat=
abase corruption, as the OP has not actually shown us the output of how the=
y are determining the missing index, and then how the reindex fixes it (alt=
hough I appreciate the pg_index query results). To put another way, user er=
ror is a much more likely explanation than anything else given the lack of =
specific data.</div><div><br></div><div>Cheers,</div></div><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div>Greg</div><div><br></div><=
div><br></div></div></div></div>

--0000000000004ccbf0064cac2739--