Re: BUG #17212: pg_amcheck fails on checking temporary relations - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: BUG #17212: pg_amcheck fails on checking temporary relations
Date
Msg-id CAH2-Wzk_pukOFY7JmdiFLsrz+Pd3V8OwgC1TH2Vd5BH5ZgK4bA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17212: pg_amcheck fails on checking temporary relations  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: BUG #17212: pg_amcheck fails on checking temporary relations
List pgsql-hackers
On Mon, Oct 11, 2021 at 11:40 AM Peter Geoghegan <pg@bowt.ie> wrote:
> A NOTICE message is supposed to be surfaced to clients (but not stored
> in the server log), pretty much by definition.
>
> It's not unreasonable to argue that I was mistaken to ever think that
> about this particular message. In fact, I suspect that I was.

> > Somebody could quite reasonably complain about this on a hot standby with millions of unlogged relations.  Actual
ERRORmessages might get lost in all the noise.
 

How about this: we can just lower the elevel, from NOTICE to DEBUG1.
We'd then be able to keep the message we have today in
verify_nbtree.c. We'd also add a matching message (and logic) to
verify_heapam.c, keeping them consistent.

I find your argument about spammy messages convincing. But it's no
less valid for any other user of amcheck. So we really should just fix
that at the amcheck level. That way you can get rid of the call to
pg_is_in_recovery() from the SQL statements in pg_amcheck, while still
fixing everything that needs to be fixed in pg_amcheck.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations
Next
From: Tom Lane
Date:
Subject: Re: Corruption with IMMUTABLE functions in index expression.