Re: "debug_invalidate_system_caches_always" is too long - Mailing list pgsql-hackers

From Robert Haas
Subject Re: "debug_invalidate_system_caches_always" is too long
Date
Msg-id CA+TgmoZtjhH=Gqp6E_ybMk0bjZ-D4dht-KYRRzyeLaOHVR5S5Q@mail.gmail.com
Whole thread Raw
In response to Re: "debug_invalidate_system_caches_always" is too long  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "debug_invalidate_system_caches_always" is too long  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jul 7, 2021 at 11:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> > The clobbering doesn't actually happen unless you turn on
> > CLOBBER_FREED_MEMORY, so it would be good to keep that separate.
>
> Fair point.  What do you think of the alternative proposals
> "debug_flush_caches", "debug_discard_caches", etc?

I like debug_discard_caches best. I have no preference between
debug_flush_caches and debug_clobber_caches; neither seems horrid. I
agree that what we're doing here is not precisely a "clobber" in the
usual sense, but the people who are apt to be using it will probably
be aware of that. Yet, it's good to try to clear things up for future
hackers, and IMHO debug_discard_caches is the clearest, so that's why
I like it a little better than the other choices.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Pipeline mode and PQpipelineSync()
Next
From: Dean Rasheed
Date:
Subject: Re: [PATCH] expand the units that pg_size_pretty supports on output