Re: BUG #8656: Duplicate data violating unique constraints

From: Maciek Sakrejda <maciek(at)heroku(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #8656: Duplicate data violating unique constraints
Date: 2013-12-05 05:29:21
Message-ID: CAKwe89A0HjOZRpZuqj70zF1QvmOxTcALNEL=a6AQdQTe+dzGKQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Interesting. That very well could be the issue. I didn't this affected
primaries.

I don't think the customer has done a VACUUM FREEZE; I'll double-check. It
looks like there were around 20 backends and 200 commits per second around
that time based on our monitoring.

=> SELECT relfrozenxid, relminmxid FROM pg_class WHERE oid =
'post'::regclass;
relfrozenxid | relminmxid
--------------+------------
17903 | 4245098283
(1 row)

$ pg_controldata $PGDATA
pg_control version number: 937
Catalog version number: 201306121
Database system identifier: 5951409877055172578
Database cluster state: in production
pg_control last modified: Thu 05 Dec 2013 05:05:13 AM UTC
Latest checkpoint location: 1D/D917DAD8
Prior checkpoint location: 1D/CF32F6C8
Latest checkpoint's REDO location: 1D/D43487E8
Latest checkpoint's REDO WAL file: 000000010000001D000000D4
Latest checkpoint's TimeLineID: 1
Latest checkpoint's PrevTimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0/1579944
Latest checkpoint's NextOID: 712704
Latest checkpoint's NextMultiXactId: 592631
Latest checkpoint's NextMultiOffset: 1236955
Latest checkpoint's oldestXID: 1845
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 1579743
Latest checkpoint's oldestMultiXid: 1
Latest checkpoint's oldestMulti's DB: 1
Time of latest checkpoint: Thu 05 Dec 2013 05:00:18 AM 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: 500
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: 1

From the description, I can't tell what this means: does this either confim
or refute that this database was affected?

Thanks,
Maciek

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dean Rasheed 2013-12-05 06:22:59 Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message Peter Eisentraut 2013-12-05 01:33:07 Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist