Re[2]: [BUGS] BUG #8757: Dublicate rows, broken primary key.

This values are present in table and not present in index.

And the reindexing index gives error:

ERROR: could not create unique index "pk_blog_blogs"
Detail: Key (id_blog)=(26) is duplicated.
Statement: REINDEX INDEX blog.pk_blog_blogs ;

Понедельник, 13 января 2014, 9:59 -03:00 от Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:
>Дмитрий Сарафанников wrote:
>> Hey ? I need the answer or some information.
>
>The first thing I would check is whether the values are present in the
>table and not the index, or are they missing altogether. Please try
>searching for them with enable_indexscan and enable_bitmapscan both set
>to OFF. This should force a sequential scan and will tell you if the
>values are completely missing from the table, or just missing in the
>index.
>
>If missing from the table, I would suspect a tqual.c problem, perhaps
>related to multixacts, as you see to have some use of them.
>
>>
>> Четверг, 9 января 2014, 20:27 +04:00 от Дмитрий Сарафанников < dimon99901(at)mail(dot)ru >:
>> >pg_control version number: 937
>> >Catalog version number: 201306121
>> >Database system identifier: 5965523135297743807
>> >Database cluster state: in production
>> >pg_control last modified: Thu 09 Jan 2014 04:23:43 PM UTC
>> >Latest checkpoint location: 263C/A2B28550
>> >Prior checkpoint location: 263C/9AC7F608
>> >Latest checkpoint's REDO location: 263C/9EC81058
>> >Latest checkpoint's REDO WAL file: 000000010000263C0000009E
>> >Latest checkpoint's TimeLineID: 1
>> >Latest checkpoint's PrevTimeLineID: 1
>> >Latest checkpoint's full_page_writes: on
>> >Latest checkpoint's NextXID: 0/3917877569
>> >Latest checkpoint's NextOID: 148656505
>> >Latest checkpoint's NextMultiXactId: 3400755
>> >Latest checkpoint's NextMultiOffset: 505332
>> >Latest checkpoint's oldestXID: 3718614222
>> >Latest checkpoint's oldestXID's DB: 16435
>> >Latest checkpoint's oldestActiveXID: 3917877507
>> >Latest checkpoint's oldestMultiXid: 3188075
>> >Latest checkpoint's oldestMulti's DB: 0
>> >Time of latest checkpoint: Thu 09 Jan 2014 04:21:13 PM UTC
>> >Fake LSN counter for unlogged rels: 0/1
>> >Minimum recovery ending location: 0/0
>> >Min recovery ending loc's timeline: 0
>> >Backup start location: 0/0
>> >Backup end location: 0/0
>> >End-of-backup record required: no
>> >Current wal_level setting: hot_standby
>> >Current max_connections setting: 200
>> >Current max_prepared_xacts setting: 0
>> >Current max_locks_per_xact setting: 64
>> >Maximum data alignment: 8
>> >Database block size: 8192
>> >Blocks per segment of large relation: 131072
>> >WAL block size: 8192
>> >Bytes per WAL segment: 16777216
>> >Maximum length of identifiers: 64
>> >Maximum columns in an index: 32
>> >Maximum size of a TOAST chunk: 1996
>> >Date/time type storage: 64-bit integers
>> >Float4 argument passing: by value
>> >Float8 argument passing: by value
>> >Data page checksum version: 0
>> >
>> >
>> >And, we noticed, that updates on rows where id_blog = 26 executes more longer then updates on other rows of this table.
>> >Четверг, 9 января 2014, 12:38 -03:00 от Alvaro Herrera < alvherre(at)2ndquadrant(dot)com >:
>> >>
>> >>
>> >>Can you please share the output of pg_controldata?
>> >>
>> >>--
>> >>Álvaro Herrera http://www.2ndQuadrant.com/
>> >>PostgreSQL Development, 24x7 Support, Training & Services
>> >
>> >
>> >--
>> >Дмитрий Сарафанников
>>
>>
>> --
>> Дмитрий Сарафанников
>
>
>--
>Álvaro Herrera http://www.2ndQuadrant.com/
>PostgreSQL Development, 24x7 Support, Training & Services

--
Дмитрий Сарафанников