Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rOjQl-006eGh-D4 for pgsql-hackers@arkaria.postgresql.org; Sat, 13 Jan 2024 19:12:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rOjQk-009CXg-6F for pgsql-hackers@arkaria.postgresql.org; Sat, 13 Jan 2024 19:12:30 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rOjQj-009CXY-T1 for pgsql-hackers@lists.postgresql.org; Sat, 13 Jan 2024 19:12:29 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rOjQh-001Ng8-Ee for pgsql-hackers@lists.postgresql.org; Sat, 13 Jan 2024 19:12:28 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 40DJCNRe1041876; Sat, 13 Jan 2024 14:12:23 -0500 From: Tom Lane To: Xiaoran Wang cc: pgsql-hackers@lists.postgresql.org, Andres Freund Subject: Re: Recovering from detoast-related catcache invalidations In-reply-to: <966599.1705166312@sss.pgh.pa.us> References: <329632.1705011663@sss.pgh.pa.us> <754826.1705090452@sss.pgh.pa.us> <793469.1705092433@sss.pgh.pa.us> <966599.1705166312@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Sat, 13 Jan 2024 12:18:32 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1041874.1705173143.1@sss.pgh.pa.us> Date: Sat, 13 Jan 2024 14:12:23 -0500 Message-ID: <1041875.1705173143@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Xiaoran Wang writes: >> Hmm, how about first checking if any invalidated shared messages have been >> accepted, then rechecking the tuple's visibility? >> If there is no invalidated shared message accepted during >> 'toast_flatten_tuple', >> there is no need to do then visibility check, then it can save several >> CPU cycles. > Meh, I'd just as soon not add the additional dependency/risk of bugs. > This is an expensive and seldom-taken code path, so I don't think > shaving a few cycles is really important. It occurred to me that this idea might be more interesting if we could encapsulate it right into systable_recheck_tuple: something like having systable_beginscan capture the current SharedInvalidMessageCounter and save it in the SysScanDesc struct, then compare in systable_recheck_tuple to possibly short-circuit that work. This'd eliminate one of the main bug hazards in the idea, namely that you might capture SharedInvalidMessageCounter too late, after something's already happened. However, the whole idea only works for catalogs that have catcaches, and the other users of systable_recheck_tuple are interested in pg_depend which doesn't. So that put a damper on my enthusiasm for the idea. regards, tom lane