From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS |
Date: | 2020-09-25 07:40:17 |
Message-ID: | CAMsr+YF=+ctXBZj3ywmvKNUjWpxmuTuUKuv-rgbHGX5i5pLstQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all
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.
-----
On a side note, to make things like this easier to use, I personally patch
all pg_regress tests to include the following at the start of each sql
input file:
\set ECHO none
-- Put per-test settings or overrides here
\set ECHO queries
then patch the expected files accordingly. That way it's easy for me to
make per-test adjustments while still running the whole suite. It's not
always practical to run just one targeted test with TESTS=foo.
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Add-runtime-control-over-CLOBBER_CACHE_ALWAYS.patch | text/x-patch | 8.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | k.jamison@fujitsu.com | 2020-09-25 08:18:55 | RE: [Patch] Optimize dropping of relation buffers using dlist |
Previous Message | torikoshia | 2020-09-25 07:28:02 | Re: Get memory contexts of an arbitrary backend process |