On Mon, 30 Nov 2020, 20:38 Anastasia Lubennikova, < a.lubennik...@postgrespro.ru> wrote:
> 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. > Thanks. I'll update it soon.
