From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, sergey(dot)frolov(at)smetarik(dot)ru |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14940: Duplicated records inspite of primary key and unique constraint |
Date: | 2017-12-01 17:17:45 |
Message-ID: | 5908ac7d-875d-0575-c6fb-06e2985e2986@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 12/01/2017 06:15 PM, Alvaro Herrera wrote:
> sergey(dot)frolov(at)smetarik(dot)ru wrote:
>
>> select ctid,xmin,xmax, id, base_id, norm_id from nb.nb_basedtl where id =
>> 11658502 ;-- expected ONE row
>>
>> (0,49);364507;0;11658502;269;46203
>> (0,49);370881;0;11658502;269;46203
>> (0,49);370882;0;11658502;269;46203
>
> Since these rows all have the same CTID, it looks like the index on id
> must be corrupt and returned the same tuple more than once. But the
> weird thing is that the xmin differs ... How can that be? Does this
> change if you set enable_indexscan and enable_bitmapscan to off?
>
> Would you try running amcheck on this index?
> https://github.com/petergeoghegan/amcheck
>
Oh, haven't noticed this. I wonder if the other cases (supposedly there
are 50 duplicate records) look the same way.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Dipesh Kamdar | 2017-12-01 17:37:39 | Re: BUG #14938: ALTER TABLE hang/ poor performance |
Previous Message | Tomas Vondra | 2017-12-01 17:15:47 | Re: BUG #14941: Vacuum crashes |