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

From Craig Ringer
Subject [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS
Date
Msg-id CAMsr+YF=+ctXBZj3ywmvKNUjWpxmuTuUKuv-rgbHGX5i5pLstQ@mail.gmail.com
Whole thread Raw
Responses Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS
List 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

pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: Get memory contexts of an arbitrary backend process
Next
From: "k.jamison@fujitsu.com"
Date:
Subject: RE: [Patch] Optimize dropping of relation buffers using dlist