1
0
mirror of https://github.com/postgres/postgres.git synced 2025-08-12 15:23:02 +03:00

Replace CLOBBER_CACHE_ALWAYS with run-time GUC

Forced cache invalidation (CLOBBER_CACHE_ALWAYS) has been impractical
to use for testing in PostgreSQL because it's so slow and because it's
toggled on/off only at build time.  It is helpful when hunting bugs in
any code that uses the sycache/relcache because causes cache
invalidations to be injected whenever it would be possible for an
invalidation to occur, whether or not one was really pending.

Address this by providing run-time control over cache clobber
behaviour using the new debug_invalidate_system_caches_always GUC.
Support is not compiled in at all unless assertions are enabled or
CLOBBER_CACHE_ENABLED is explicitly defined at compile time.  It
defaults to 0 if compiled in, so it has negligible effect on assert
build performance by default.

When support is compiled in, test code can now set
debug_invalidate_system_caches_always=1 locally to a backend to test
specific queries, functions, extensions, etc.  Or tests can toggle it
globally for a specific test case while retaining normal performance
during test setup and teardown.

For backwards compatibility with existing test harnesses and scripts,
debug_invalidate_system_caches_always defaults to 1 if
CLOBBER_CACHE_ALWAYS is defined, and to 3 if CLOBBER_CACHE_RECURSIVE
is defined.

CLOBBER_CACHE_ENABLED is now visible in pg_config_manual.h, as is the
related RECOVER_RELATION_BUILD_MEMORY setting for the relcache.

Author: Craig Ringer <craig.ringer@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/flat/CAMsr+YF=+ctXBZj3ywmvKNUjWpxmuTuUKuv-rgbHGX5i5pLstQ@mail.gmail.com
This commit is contained in:
Peter Eisentraut
2021-01-06 10:15:19 +01:00
parent 8900b5a9d5
commit 4656e3d668
9 changed files with 169 additions and 54 deletions

View File

@@ -109,6 +109,7 @@
#include "storage/sinval.h"
#include "storage/smgr.h"
#include "utils/catcache.h"
#include "utils/guc.h"
#include "utils/inval.h"
#include "utils/memdebug.h"
#include "utils/memutils.h"
@@ -179,6 +180,8 @@ static SharedInvalidationMessage *SharedInvalidMessagesArray;
static int numSharedInvalidMessagesArray;
static int maxSharedInvalidMessagesArray;
/* GUC storage */
int debug_invalidate_system_caches_always = 0;
/*
* Dynamically-registered callback functions. Current implementation
@@ -689,35 +692,32 @@ AcceptInvalidationMessages(void)
/*
* Test code to force cache flushes anytime a flush could happen.
*
* If used with CLOBBER_FREED_MEMORY, CLOBBER_CACHE_ALWAYS provides a
* fairly thorough test that the system contains no cache-flush hazards.
* However, it also makes the system unbelievably slow --- the regression
* tests take about 100 times longer than normal.
* This helps detect intermittent faults caused by code that reads a
* cache entry and then performs an action that could invalidate the entry,
* but rarely actually does so. This can spot issues that would otherwise
* only arise with badly timed concurrent DDL, for example.
*
* If you're a glutton for punishment, try CLOBBER_CACHE_RECURSIVELY. This
* slows things by at least a factor of 10000, so I wouldn't suggest
* trying to run the entire regression tests that way. It's useful to try
* a few simple tests, to make sure that cache reload isn't subject to
* internal cache-flush hazards, but after you've done a few thousand
* recursive reloads it's unlikely you'll learn more.
* The default debug_invalidate_system_caches_always = 0 does no forced cache flushes.
*
* If used with CLOBBER_FREED_MEMORY, debug_invalidate_system_caches_always = 1
* (CLOBBER_CACHE_ALWAYS) provides a fairly thorough test that the system
* contains no cache-flush hazards. However, it also makes the system
* unbelievably slow --- the regression tests take about 100 times longer
* than normal.
*
* If you're a glutton for punishment, try debug_invalidate_system_caches_always = 3
* (CLOBBER_CACHE_RECURSIVELY). This slows things by at least a factor
* of 10000, so I wouldn't suggest trying to run the entire regression
* tests that way. It's useful to try a few simple tests, to make sure
* that cache reload isn't subject to internal cache-flush hazards, but
* after you've done a few thousand recursive reloads it's unlikely
* you'll learn more.
*/
#if defined(CLOBBER_CACHE_ALWAYS)
{
static bool in_recursion = false;
if (!in_recursion)
{
in_recursion = true;
InvalidateSystemCaches();
in_recursion = false;
}
}
#elif defined(CLOBBER_CACHE_RECURSIVELY)
#ifdef CLOBBER_CACHE_ENABLED
{
static int recursion_depth = 0;
/* Maximum depth is arbitrary depending on your threshold of pain */
if (recursion_depth < 3)
if (recursion_depth < debug_invalidate_system_caches_always)
{
recursion_depth++;
InvalidateSystemCaches();