From: Tom Lane <tgl@sss.pgh.pa.us>
To: talmoshe24@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18756: Postgres corruption
In-reply-to: <18756-dedadb77ca3668b8@postgresql.org>
References: <18756-dedadb77ca3668b8@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sun, 29 Dec 2024 18:49:34 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <3724194.1735513819.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 29 Dec 2024 18:10:19 -0500
Message-ID: <3724195.1735513819@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3724195.1735513819%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> We saw a corruption in 3 different environments in one of the unique ind=
exes
> (named =E2=80=9Cnpn=E2=80=9D) in =E2=80=9Cfiles=E2=80=9D table.
> It seems as if not all the rows (that should be part of this index) in t=
he
> table are indexed, and therefore =E2=80=9Cduplicated=E2=80=9D rows (rows=
 that violates the
> index constraint) are allowed to be inserted to DB.

Are any of the indexed columns of string types (text, varchar, etc)?
And have you upgraded the underlying OS since creating the index?
If so, you've likely been bit by locale changes.  See

https://wiki.postgresql.org/wiki/Locale_data_changes

			regards, tom lane