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
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 |