On 27.10.2020 11:34, Peter Eisentraut wrote:
On 2020-09-25 09:40, Craig Ringer wrote:
While working on extensions I've often wanted to enable cache
clobbering for a targeted piece of code, without paying the price of
running it for all backends during postgres startup and any initial
setup tasks that are required.
So here's a patch that, when CLOBBER_CACHE_ALWAYS or
CLOBBER_CACHE_RECURSIVE are defined, adds a GUC named
clobber_cache_depth . It defaults to 1 for CLOBBER_CACHE_ALWAYS or 3
for CLOBBER_CACHE_RECURSIVE to match the existing compiled-in
behaviour. But with this change it's now possible to run Pg with
clobber_cache_depth=0 then set it to 1 only for targeted tests.
clobber_cache_depth is treated as an unknown GUC if Pg was not built
with CLOBBER_CACHE_ALWAYS or CLOBBER_CACHE_RECURSIVE defined.
I think it would be great if the cache clobber code is always compiled
in (but turned off) when building with assertions. The would reduce
the number of hoops to jump through to actually use this locally and
reduce the number of surprises from the build farm.
For backward compatibility, you can arrange it so that the built-in
default of clobber_cache_depth is 1 or 3 if CLOBBER_CACHE_ALWAYS or
CLOBBER_CACHE_RECURSIVE are defined.
Status update for a commitfest entry.
This thread was inactive during the commitfest, so I am going to mark it
as "Returned with Feedback".
Craig, are you planning to continue working on it? The proposed idea is
great and it looks like the patch needs only a minor improvement.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
