From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Kenneth Marshall <ktm(at)rice(dot)edu>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: unique index violation after pg_upgrade to PG10 |
Date: | 2017-10-24 22:28:40 |
Message-ID: | 20171024222839.GX21735@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 24, 2017 at 02:57:47PM -0700, Peter Geoghegan wrote:
> On Tue, Oct 24, 2017 at 1:11 PM, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > ..which I gather just verifies that the index is corrupt, not sure if there's
> > anything else to do with it? Note, we've already removed the duplicate rows.
> Maybe you could try verifying a different index on the same table with
> "heapallindexed", too. Perhaps that would fail in a more interesting
> way.
The only other index seems fine:
[pryzbyj(at)database ~]$ psql --port 5678 ts -txc "SELECT bt_index_parent_check('sites_pkey'::regclass::oid, heapallindexed=>True)"
bt_index_parent_check |
[pryzbyj(at)database ~]$ psql --port 5678 ts -txc "SELECT bt_index_check('sites_pkey'::regclass::oid, heapallindexed=>True)"
bt_index_check |
> You're using LVM snapshots -- I hope that you're aware that they're
> not guaranteed to be consistent across logical volumes. There are a
> few different ways that they could cause corruption like this if you
> weren't careful. (In general, I wouldn't recommend using LVM snapshots
> as any kind of backup solution.)
Right, I asked a coworker to create the snapshot before trying to fix the
immediate problem, as a forensic measure. We have postgres on just one LVM LV.
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-10-24 23:56:27 | Re: per-sesson errors after interrupting CLUSTER pg_attrdef |
Previous Message | Justin Pryzby | 2017-10-24 22:27:52 | Re: unique index violation after pg_upgrade to PG10 |