Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: abbas alizadeh <ramkly@yahoo.com>
Mime-Version: 1.0 (1.0)
Subject: Re: Duplicate data even with primary keys enabled
Date: Sat, 29 Oct 2022 15:20:58 +0400
Message-Id: <C254B8F9-9779-4F8F-BDAB-C55E7088FA7C@yahoo.com>
References: <2102110489.726355.1667002718732@office.mailbox.org>
Cc: Scott Ribe <scott_ribe@elevated-dev.com>,
 Teju Jakkidi vlogs <teja.jakkidi05@gmail.com>,
 Holger Jakobs <holger@jakobs.com>, pgsql-admin@lists.postgresql.org
In-Reply-To: <2102110489.726355.1667002718732@office.mailbox.org>
To: Erik Wienhold <ewie@ewie.name>
Content-Length: 903
Archived-At: 
 <https://www.postgresql.org/message-id/C254B8F9-9779-4F8F-BDAB-C55E7088FA7C%40yahoo.com>
Precedence: bulk

Hi all.
I faced the same issue last week.=20
We had duplicated records on primary key.=20
Postgresql version is 14.4


Sent from my iPhone

> On 29 Oct 2022, at 4:18 AM, Erik Wienhold <ewie@ewie.name> wrote:
>=20
> =EF=BB=BF
>>=20
>> On 28/10/2022 22:50 CEST Scott Ribe <scott_ribe@elevated-dev.com> wrote:
>>=20
>> A corrupted index could allow that to happen by failing to catch the dupl=
icate
>> insert. I suppose it might also be able to cause the same row to be retur=
ned
>> multiple times--although I have personally only ever seen corrupted index=
es
>> cause rows to not be found.
>=20
> I think it should be possible to tell those two cases apart by looking at s=
ystem
> column ctid.  The ctid should be the same for duplicate rows if the same r=
ow is
> found multiple times in the index.  Different ctid if the corrupted index
> allowed INSERT with duplicates.
>=20
> --
> Erik
>=20
>=20