Re: BUG #8757: Dublicate rows, broken primary key. - Mailing list pgsql-bugs

Дмитрий Сарафанников 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@mail.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@2ndquadrant.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