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

From Bharath Rupireddy
Subject Re: postgres_fdw - make cached connection functions tests meaningful
Date
Msg-id CALj2ACXZsp21gYYNtPAP6DL=8-vbuNLLcOqv5_mTx4nqz7JRAg@mail.gmail.com
Whole thread Raw
In response to Re: postgres_fdw - make cached connection functions tests meaningful  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jul 17, 2021 at 9:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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.

Thanks. I'm fine with dropping this patch, hence I marked the CF entry
as "rejected".

Regards,
Bharath Rupireddy.



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Numeric x^y for negative x
Next
From: Bharath Rupireddy
Date:
Subject: Re: Printing backtrace of postgres processes