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

pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed

From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Pavel Borisov <pashkin.elfe@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations
Date: Mon, 11 Oct 2021 12:25:03 -0700
Message-ID: <AB2D6C6B-9073-45AB-9574-A6E37B855CF3@enterprisedb.com> (raw)
In-Reply-To: <CAH2-Wzk_pukOFY7JmdiFLsrz+Pd3V8OwgC1TH2Vd5BH5ZgK4bA@mail.gmail.com>
References: <17212-34dd4a1d6bba98bf@postgresql.org>
	<CAH2-Wz=bw-Uk2yoOq7yevC9hyMGgZ2Ud34nd9YJJPXJ3pkVcrw@mail.gmail.com>
	<E85855BD-C063-4B24-9EAA-02DECC8F42B9@enterprisedb.com>
	<E283B45F-5745-49C9-BBC7-99876E2FABD1@enterprisedb.com>
	<f42de8ec-f219-0922-93b3-37a72bba1feb@gmail.com>
	<28B36E41-1E8F-4DC1-A924-711621BA4972@enterprisedb.com>
	<CAH2-Wz=v4py=c79J7wpdVmQMkd8rO7gj5Ur5Dp4E0y7aQUz6cg@mail.gmail.com>
	<386F66EE-DEFD-42EA-9DB2-102BF3414669@enterprisedb.com>
	<CAH2-Wzkwb+1GSONMrXByHhgkzD-N59A_kFcvsoA_+M9cNNHm5g@mail.gmail.com>
	<CA+TgmobJnZE6WMw1y+N9ts36nsbL_un0CYB_khieg8rOa86RBw@mail.gmail.com>
	<CAH2-Wzm02e=jAarpzeZGyK8JyXTvuHCfJ9KC5svosD72nROKrw@mail.gmail.com>
	<B2BDB87C-8288-436E-B3DC-8AEB92FEB8F1@enterprisedb.com>
	<CAH2-Wz=WYdmbc1k8Lr2P4eQeYkh1UYvyDigzrvukejcWc2jKOA@mail.gmail.com>
	<c422a1aa-81c0-0762-0971-9a026cf2aa79@gmail.com>
	<CAH2-WzndLb0-GZcshTJGw6u6SQrJ5puyFiFYh-DWR8ue2zQuvA@mail.gmail.com>
	<CALT9ZEGhuXiH54VgyVJ65V+ccGqPqHTduBM4saPWSD2mrD5C6Q@mail.gmail.com>
	<F824CD5F-C82F-451C-AE67-9AD31447424A@enterprisedb.com>
	<CAH2-WznaYWowxxFaGK6Hv=SUQYS2-r7dQZJFWyDT_W6GGtuCjA@mail.gmail.com>
	<63FF68F5-683D-423E-A667-9C00441101A5@enterprisedb.com>
	<CAH2-Wz=8RP6izkLF=P_bFUK-CyTsO09hQ1-ZsC9P4Qiz3CughQ@mail.gmail.com>
	<561CE3DB-5CBC-44BF-9A3E-1D7FAEB123E0@enterprisedb.com>
	<CA+TgmobtAq9sNa0Z4QNx0xiP4NAobuGOnOirTWdJajkTRFvXNw@mail.gmail.com>
	<CAH2-WzmJkVKFSqJd2_uy07jPg-LW0yCHh0fgA8rFkdyk6FZOnQ@mail.gmail.com>
	<CA+TgmoYa5exExaONEnGBWRdi7A3=FKuKzewY8DXTj6+045wiFQ@mail.gmail.com>
	<CAH2-WzkwRUayddmb3uxCadV_y--DHfY+UMmjtOokiAO2xNh5fA@mail.gmail.com>
	<CA+Tgmoat1M4MAqUQM1H+bkWR=wXmi33bB0YRR=xaFk9ADs5Jeg@mail.gmail.com>
	<CAH2-Wzk3NzXYXsUKWBFuBm6aiXTh-_L2Dm9wPqfFenUvG+VbRw@mail.gmail.com>
	<543F3BF3-EDED-4C52-AF05-623921B6C409@enterprisedb.com>
	<CAH2-WzkXphRHgbaUXqMgb7SBmc_VbwdyWGYqphV6KbOH7stfxA@mail.gmail.com>
	<55A2BFE7-AAAF-4A64-BD3A-5C98EA982267@enterprisedb.com>
	<CAH2-WzniogVqNuWzNVLOKjkd8FBcSry29hN9=wiROUPw92fmGg@mail.gmail.com>
	<07159C9A-40DA-47BF-B2F4-203F5AC00890@enterprisedb.com>
	<CAH2-Wzkt-umhXfR1nqy=ZDXMfoN3LDK4W5VtchfWyRAuPWxtnA@mail.gmail.com>
	<40DB088B-C96F-49B2-BC84-BDC8D35C7E97@enterprisedb.com>
	<CAH2-Wzne7L9fX2LdZ9enNZpO2wuqbrsubCw2thH__CC_nZazjw@mail.gmail.com>
	<0B7DA7A4-2872-485B-BFDD-BF8E9BB07B26@enterprisedb.com>
	<CAH2-Wz=YnyANaKQDfx9pg0YNPS-LY66CXQrUzED4RgmmdS7utA@mail.gmail.com>
	<CAH2-Wzk_pukOFY7JmdiFLsrz+Pd3V8OwgC1TH2Vd5BH5ZgK4bA@mail.gmail.com>



> On Oct 11, 2021, at 11:53 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> 
> 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 ERROR messages 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.

Your proposal sounds good.  Let me try it and get back to you shortly.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

view thread (83+ messages)  latest in thread

Message-ID: <AB2D6C6B-9073-45AB-9574-A6E37B855CF3@enterprisedb.com>
Permalink:  ../AB2D6C6B-9073-45AB-9574-A6E37B855CF3@enterprisedb.com/
Also on:    postgresql.org/message-id/AB2D6C6B-9073-45AB-9574-A6E37B855CF3@enterprisedb.com

 ·

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: mark.dilger@enterprisedb.com, pg@bowt.ie, robertmhaas@gmail.com, pashkin.elfe@gmail.com, exclusion@gmail.com, pgsql-hackers@postgresql.org
  Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations
  In-Reply-To: <AB2D6C6B-9073-45AB-9574-A6E37B855CF3@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox