Re: Injection points: preloading and runtime arguments - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Injection points: preloading and runtime arguments
Date
Msg-id ZpcqPaM6IYy2Xn7m@paquier.xyz
Whole thread Raw
In response to Re: Injection points: preloading and runtime arguments  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Injection points: preloading and runtime arguments
List pgsql-hackers
On Tue, Jul 16, 2024 at 11:20:57AM +0300, Heikki Linnakangas wrote:
> The "direct" argument to InjectionPointCacheRefresh() feels a bit weird.
> Also weird that it still checks ActiveInjectionPoints->max_inuse, even
> though it otherwise operates on the cached version only. I think you can
> just call injection_point_cache_get() directly from InjectionPointCached(),
> per attached.

My point was just to be more aggressive with the cache correctness
even in this context.  You've also mentioned upthread the point that
we should worry about a concurrent detach, which is something that
injection_point_cache_get() alone is not able to do as we would not
cross-check the generation with what's in the shared area, so I also
saw a point about being more aggressive with the check here.

It works for me to do as you are proposing at the end, that could
always be changed if there are more arguments in favor of a different
behavior that plays more with the shmem data.

> I also rephrased the docs section a bit, focusing more on why and how you
> use the LOAD/CACHED pair, and less on the mechanics of how it works.

I'm OK with that, as well.  Thanks.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Possible incorrect row estimation for Gather paths
Next
From: Michael Paquier
Date:
Subject: Re: improve performance of pg_dump with many sequences