| From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
|---|---|
| To: | Wim Rouquart <wim(dot)rouquart(at)kbc(dot)be> |
| Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Index (primary key) corrupt? |
| Date: | 2026-03-09 15:24:15 |
| Message-ID: | CAKAnmmLsxdt51sp-w0JxMi0haGXHFKD2pXURfOSOa5iVzjni4w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Mar 9, 2026 at 10:12 AM Wim Rouquart <wim(dot)rouquart(at)kbc(dot)be> wrote:
> I already saw finding the actual cause as a 'lost cause' as these things
> tend to happen, however what bothers me most is that a tool like amcheck
> which is supposed to find corruption also shows up with no result.
>
Well, no, these things really should not happen. :)
It may be too late, but it would be real interesting to see this query both
before and after the REINDEX:
select * from pg_index where indrelid = 'bcf_work_type'::regclass and
indisprimary;
An incorrect indrelid is one way I can think of as to how pg_dump would
miss it, but that wouldn't explain why reindex would subsequently fix it.
Cheers,
Greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2026-03-09 15:37:26 | Re: Index (primary key) corrupt? |
| Previous Message | Adrian Klaver | 2026-03-09 14:52:54 | Re: Index (primary key) corrupt? |