Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS
Date
Msg-id CAGRY4nyFzr6RF5hbyRq9JeN2kXd7Z4yU3sMyrRqCwG2DjWDuEw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers


On Tue, 5 Jan 2021, 22:41 Peter Eisentraut, <peter.eisentraut@2ndquadrant.com> wrote:
On 2020-12-03 07:01, Craig Ringer wrote:
> To try it out, apply the patch (git am), build with --enable-cassert,
> then compare:
>
>     make -C src/test/regress check
>
> and
>
>     PGOPTIONS="-c debug_clobber_cache_depth=1" \
>     make -C src/test/regress check
>
> The speed difference will be obvious if nothing else!

This is a really useful feature change.  I have a version that I'm happy
to commit, but I wanted to check on the name of the setting.  The
proposed name arose during the discussion when it was just to set the
recursion depth but not enable the feature altogether, so I think that
name is a bit misleading now.  We could reuse the old macro name, as in
clobber_cache_always=N, which is very recognizable.  But the feature
itself doesn't clobber anything (that's done by CLOBBER_FREED_MEMORY),
so most accurate would be something like
invalidate_system_caches_always=N.  Thoughts?

Modulo typo, I think that's a better name.

Perhaps debug_invalidate_system_caches_always ? It's a bit long but we use the debug prefix elsewhere too.



--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Replication protocol pipelining edge case
Next
From: Tom Lane
Date:
Subject: Re: allow to \dtS+ pg_toast.*