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 1m133d-0005Ro-W9 for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Jul 2021 08:37:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m133c-0003Uu-QU for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Jul 2021 08:37:24 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m133c-0003Ul-IO for pgsql-hackers@lists.postgresql.org; Wed, 07 Jul 2021 08:37:24 +0000 Received: from forward1-smtp.messagingengine.com ([66.111.4.223]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m133Z-0008Mn-Ag for pgsql-hackers@lists.postgresql.org; Wed, 07 Jul 2021 08:37:23 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.nyi.internal (Postfix) with ESMTP id F2C5E19409E0; Wed, 7 Jul 2021 04:37:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 07 Jul 2021 04:37:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Xhlch5s5fuZ0uAShZHKDoS1A7AUk1LgZFv5roqCaL gQ=; b=w1bZ3KsP/UFuIpGNS5SfY6w2626zeNMV4ioN6xzaFjB3/kfQXkefroyDL JZr5uNRbJfSTQ4E5Hs0ao6zRmRRsFhA0YoiVbTS8UcKMZCE/+Sz9g2ztt93edWzz Olrkv+uFX17HsJ1RDZDolATCb+WbFFcvXYCIJQIwKsx4XZ1OARE1uYv9ThLLh1Li 6KHe57xNvIWf38sHLF9i/kgF0TfSDHzUNcHhifAiOtI1CN0dsWUXczFPVR7U5oOI sb2cYMp+GnC4+DxsuBGYLkRjwJrcq49OVVyuJ8VUMzjrVjhc7LLSJ41ACJbUTc7r 485SYtZ5At8YJSSMpwQX7Bdv49OpA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtddvgddthecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthejre dttdefjeenucfhrhhomheprfgvthgvrhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdr vghishgvnhhtrhgruhhtsegvnhhtvghrphhrihhsvggusgdrtghomheqnecuggftrfgrth htvghrnhepleevheehueeiudeiteeitdekueetleefteejffeiffdugedvffdvffdtiedv ueeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepph gvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Jul 2021 04:37:16 -0400 (EDT) Subject: Re: "debug_invalidate_system_caches_always" is too long To: Tom Lane , pgsql-hackers@lists.postgresql.org References: <1374320.1625430433@sss.pgh.pa.us> From: Peter Eisentraut Message-ID: Date: Wed, 7 Jul 2021 10:37:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <1374320.1625430433@sss.pgh.pa.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 04.07.21 22:27, Tom Lane wrote: > I do agree with the "debug_" prefix given that it's now visible to > users. However, it doesn't seem that hard to save some space in > the rest of the name. The word "system" is adding nothing of value, > and the word "always" seems rather confusing --- if it does > something "always", why is there more than one level? So a simple > proposal is to rename it to "debug_invalidate_caches". I think we can definitely drop the "always". Not so much the "system", since there are other caches, but it would be ok if we want it shorter. > 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. The clobbering doesn't actually happen unless you turn on CLOBBER_FREED_MEMORY, so it would be good to keep that separate.