On Tue, Oct 24, 2017 at 11:48 AM, Kenneth Marshall <k...@rice.edu> wrote: >> Really ? pg_repack "found" and was victim to the duplicate keys, and rolled >> back its work. The CSV logs clearly show that our application INSERTed rows >> which are duplicates. >> >> [pryzbyj@database ~]$ rpm -qa pg_repack10 >> pg_repack10-1.4.2-1.rhel6.x86_64 >> >> Justin > > Hi Justin, > > I just dealt with a similar problem with pg_repack and a PostgreSQL 9.5 DB, > the exact same error. It seemed to caused by a tuple visibility issue that > allowed the "working" unique index to be built, even though a duplicate row > existed. Then the next pg_repack would fail with the error you got. In our > case I needed the locality of reference to keep the DB performance acceptable > and it was not a critical issue if there was a duplicate. We would remove the > duplicates if we had a failure. We never had a problem with the NO pg_repack > scenarios.
A new, enhanced version of the corruption detection tool amcheck is now available, and has both apt + yum packages available: https://github.com/petergeoghegan/amcheck Unlike the version in Postgres 10, this enhanced version (V1.2) has "heapallindexed" verification, which is really what you want here. If you install it, and run it against the unique index in question (with "heapallindexed" verification), that could help. It might provide a more useful diagnostic message. This is very new, so do let me know how you get on if you try it out. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
