From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS |
Date: | 2020-10-27 08:34:48 |
Message-ID: | 3b81fad0-c1a6-97cd-299e-ab53c73fdfeb@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2020-10-27 08:38:24 | Re: [PATCH] remove deprecated v8.2 containment operators |
Previous Message | Peter Eisentraut | 2020-10-27 08:19:57 | Re: [patch] [doc] Clarify that signal functions have no feedback |