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
|
Список | 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 по дате отправления: