Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0hij-0004f9-Hg for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jul 2021 09:50:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m0hii-0004jT-Hq for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jul 2021 09:50:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0hii-0004jK-A0 for pgsql-hackers@lists.postgresql.org; Tue, 06 Jul 2021 09:50:24 +0000 Received: from relay2-d.mail.gandi.net ([217.70.183.194]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0hif-0006lV-Ln for pgsql-hackers@lists.postgresql.org; Tue, 06 Jul 2021 09:50:23 +0000 Received: (Authenticated sender: adsend@dunslane.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 170C140005; Tue, 6 Jul 2021 09:50:16 +0000 (UTC) Subject: Re: "debug_invalidate_system_caches_always" is too long To: Bharath Rupireddy , Tom Lane Cc: Noah Misch , PostgreSQL Hackers References: <1374320.1625430433@sss.pgh.pa.us> <20210704211234.GD2421985@rfd.leadboat.com> <1492832.1625512421@sss.pgh.pa.us> From: Andrew Dunstan Message-ID: <5f1332ab-d2ee-e31d-ecf7-62cc7d150b09@dunslane.net> Date: Tue, 6 Jul 2021 05:50:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 7/5/21 11:46 PM, Bharath Rupireddy wrote: > On Tue, Jul 6, 2021 at 12:43 AM Tom Lane wrote: >> Noah Misch writes: >>> On Sun, Jul 04, 2021 at 04:27:13PM -0400, Tom Lane wrote: >>>> However, I think we should also give serious consideration to >>>> "debug_clobber_cache" or "debug_clobber_cache_always" for continuity >>>> with past practice (though it still feels like "always" is a good >>>> word to lose now). "debug_clobber_caches" is another reasonable >>>> variant. >>> https://en.wikipedia.org/wiki/Clobbering refers to cases where storage had no >>> changes to its accessibility but now contains different data. That doesn't >>> match InvalidateSystemCaches() especially well, so I think dropping that word >>> has been a good step. Some other shorter terms could be debug_flush_caches, >>> debug_rebuild_caches, or debug_expire_caches. (debug_caches is tempting, but >>> that may ensnare folks looking for extra logging rather than a big slowdown.) >> I like "debug_flush_caches" --- it's short and accurate. > Do we always flush the cache entries into the disk? Sometimes we just > invalidate the cache entries in the registered invalidation callbacks, > right? Since we already use the term "clobber" in the user visible > config option --clobber-cache, isn't it consistent to use > debug_clobber_caches? > I think 'flush' here means simply 'discard'. Maybe that would be a better word to use. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com