| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
| Date: | 2021-10-06 06:21:00 |
| Message-ID: | CAH2-WzndLb0-GZcshTJGw6u6SQrJ5puyFiFYh-DWR8ue2zQuvA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Tue, Oct 5, 2021 at 11:00 PM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> I think that ideally pg_amcheck should not fail on a live database, that
> does not contain corrupted data, and should not affect the database
> usage by other users (as it's "only a check").
I agree that that's ideal. As you said, one or two narrow exceptions
may need to be made -- cases where there is unavoidable though weird
ambiguity (and not a report of true corruption). Overall the user
should never see failure from pg_amcheck unless the database is
corrupt, or unless things are defined in a pretty odd way, that
creates ambiguity. Ordinary DDL certainly doesn't count as unusual
here.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2021-10-06 08:00:00 | BUG #17216: No Password Provided Error - uncaught exception |
| Previous Message | Alexander Lakhin | 2021-10-06 06:00:00 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-10-06 06:28:24 | More business with $Test::Builder::Level in the TAP tests |
| Previous Message | Craig Ringer | 2021-10-06 06:11:51 | Re: Windows crash / abort handling |