| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Larry Rosenman <ler(at)lerctr(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: How am I supposed to fix this? |
| Date: | 2019-08-06 17:30:21 |
| Message-ID: | CAH2-WzmMabndd+JoEdC6V-wDQm7CPDgfu-d6rH3=0DXtD-ZdZQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 6, 2019 at 10:19 AM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> The question is how much other data corruption is there ...
Larry could try running amcheck on the other indexes. Just the basic
bt_check_index() checks should be enough to detect problems like this.
They can be run fairly non-disruptively. Something like this should do
it:
SELECT bt_index_check(index => c.oid),
c.relname,
c.relpages
FROM pg_index i
JOIN pg_opclass op ON i.indclass[0] = op.oid
JOIN pg_am am ON op.opcmethod = am.oid
JOIN pg_class c ON i.indexrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE am.amname = 'btree'
-- Don't check temp tables, which may be from another session:
AND c.relpersistence != 't'
-- Function may throw an error when this is omitted:
AND c.relkind = 'i' AND i.indisready AND i.indisvalid
ORDER BY c.relpages DESC;
If this takes too long, you can always adjust the query to only verify
system indexes or TOAST indexes.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Larry Rosenman | 2019-08-06 17:34:26 | Re: How am I supposed to fix this? |
| Previous Message | Alvaro Herrera | 2019-08-06 17:20:47 | Re: How am I supposed to fix this? |