Re: BUG #17212: pg_amcheck fails on checking temporary relations

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: BUG #17212: pg_amcheck fails on checking temporary relations
Дата
Msg-id CAH2-Wzk_pukOFY7JmdiFLsrz+Pd3V8OwgC1TH2Vd5BH5ZgK4bA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17212: pg_amcheck fails on checking temporary relations  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: BUG #17212: pg_amcheck fails on checking temporary relations  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: BUG #17212: pg_amcheck fails on checking temporary relations
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Corruption with IMMUTABLE functions in index expression.