Re: postgres_fdw - make cached connection functions tests meaningful - Mailing list pgsql-hackers

From Tom Lane
Subject Re: postgres_fdw - make cached connection functions tests meaningful
Date
Msg-id 70649.1626538019@sss.pgh.pa.us
Whole thread Raw
In response to Re: postgres_fdw - make cached connection functions tests meaningful  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: postgres_fdw - make cached connection functions tests meaningful
List pgsql-hackers
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes:
> On Thu, Jul 15, 2021 at 3:48 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> More generally, though, I am not sure that I believe the premise of
>> this patch.  AFAICS it's assuming that forcing debug_discard_caches
>> off guarantees zero cache flushes, which it does not.

> Can the setting debug_discard_caches = 0 still make extra
> flushes/discards (not the regular cache flushes/discards that happen
> because of alters or changes in the cached elements)? My understanding
> was that debug_discard_caches = 0, disables all the extra flushes with
> clobber cache builds. If my understanding wasn't right, isn't it good
> to mention it somewhere in the documentation or in the source code?

The reason for this mechanism is that cache flushes can be triggered
at any time by sinval messages from other processes (e.g., background
autovacuums).  Setting debug_discard_caches allows us to exercise
that possibility exhaustively and make sure that the code is proof
against cache entries disappearing unexpectedly.  Not setting
debug_discard_caches doesn't mean that that can't happen, only that
you can't predict when it will happen.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: What are exactly bootstrap processes, auxiliary processes, standalone backends, normal backends(user sessions)?
Next
From: Soumyadeep Chakraborty
Date:
Subject: Re: A micro-optimisation for ProcSendSignal()