Re: Injection points: preloading and runtime arguments

2024-08-06 Thread Andrey M. Borodin
> On 6 Aug 2024, at 12:47, Michael Paquier wrote: > > Hmm. How about loading injection_points with shared_preload_libraries > now that it has a _PG_init() thanks to 75534436a477 to take care of > the initialization you need here? We could add two hooks to request > some shmem based on a size

Re: Injection points: preloading and runtime arguments

2024-08-06 Thread Michael Paquier
On Sun, Aug 04, 2024 at 01:02:22AM +0900, Michael Paquier wrote: > On Fri, Aug 02, 2024 at 07:03:58PM +0300, Andrey M. Borodin wrote: > > The test works fine with SQL interface “select > > injection_points_load('get-new-multixact-id');”. > > Yes, just use a load() here to make sure that the DSM re

Re: Injection points: preloading and runtime arguments

2024-08-03 Thread Michael Paquier
On Fri, Aug 02, 2024 at 07:03:58PM +0300, Andrey M. Borodin wrote: > The test works fine with SQL interface “select > injection_points_load('get-new-multixact-id');”. Yes, just use a load() here to make sure that the DSM required by the waits are properly initialized before entering in the critica

Re: Injection points: preloading and runtime arguments

2024-08-02 Thread Andrey M. Borodin
> On 18 Jul 2024, at 03:55, Michael Paquier wrote: > > If there is anything else you would like to see adjusted in this area, > please let me know. I’ve tried to switch my multixact test to new INJECTION_POINT_CACHED… and it does not work for me. Could you please take a look? 2024-08-02 18:5

Re: Injection points: preloading and runtime arguments

2024-07-17 Thread Michael Paquier
On Wed, Jul 17, 2024 at 11:19:41AM +0900, Michael Paquier wrote: > 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 have taken some time this morning and appli

Re: Injection points: preloading and runtime arguments

2024-07-16 Thread Michael Paquier
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 c

Re: Injection points: preloading and runtime arguments

2024-07-16 Thread Heikki Linnakangas
On 16/07/2024 07:09, Michael Paquier wrote: On Wed, Jul 10, 2024 at 01:16:15PM +0900, Michael Paquier wrote: You mean with something that does a injection_point_cache_get() followed by a callback run if anything is found in the local cache? Why not. Based on what you have posted at [1], it look

Re: Injection points: preloading and runtime arguments

2024-07-15 Thread Michael Paquier
On Wed, Jul 10, 2024 at 01:16:15PM +0900, Michael Paquier wrote: > You mean with something that does a injection_point_cache_get() > followed by a callback run if anything is found in the local cache? > Why not. Based on what you have posted at [1], it looks like this had > better check the conten

Re: Injection points: preloading and runtime arguments

2024-07-09 Thread Michael Paquier
On Tue, Jul 09, 2024 at 12:08:26PM +0300, Heikki Linnakangas wrote: > And the injection point is attached in between the INJECTION_POINT_LOAD() > and INJECTION_POINT() calls, you will still get an assertion failure. For a > testing facility, maybe that's acceptable, but it could be fixed pretty > e

Re: Injection points: preloading and runtime arguments

2024-07-09 Thread Heikki Linnakangas
On 05/07/2024 12:16, Michael Paquier wrote: On Mon, Jun 10, 2024 at 03:10:33PM +0900, Michael Paquier wrote: OK, cool. I'll try to get that into the tree once v18 opens up. And I've spent more time on this one, and applied it to v18 after some slight tweaks. If you do: INJECTION_POINT_LOAD

Re: Injection points: preloading and runtime arguments

2024-07-05 Thread Michael Paquier
On Mon, Jun 10, 2024 at 03:10:33PM +0900, Michael Paquier wrote: > OK, cool. I'll try to get that into the tree once v18 opens up. And I've spent more time on this one, and applied it to v18 after some slight tweaks. Please feel free to re-post your tests with multixacts, Andrey. -- Michael si

Re: Injection points: preloading and runtime arguments

2024-06-09 Thread Michael Paquier
On Sat, Jun 08, 2024 at 04:52:25PM +0500, Andrey M. Borodin wrote: > Alvaro, here’s the test for multixact CV sleep that I was talking > about on PGConf. > It is needed to test [0]. It is based on loaded injection > points. > This technique is not committed yet, but the patch looks good. OK, cool

Re: Injection points: preloading and runtime arguments

2024-06-08 Thread Andrey M. Borodin
> On 7 Jun 2024, at 04:38, Michael Paquier wrote: Thanks Michael! Tests of injection points with injection points are neat :) Alvaro, here’s the test for multixact CV sleep that I was talking about on PGConf. It is needed to test [0]. It is based on loaded injection points. This technique i

Re: Injection points: preloading and runtime arguments

2024-06-06 Thread Michael Paquier
On Thu, Jun 06, 2024 at 03:47:47PM +0500, Andrey M. Borodin wrote: > Is it OK to detach() before wakeup()? Or, perhaps, can a detach() do a > wakeup() automatically? It is OK to do a detach before a wakeup. Noah has been relying on this behavior in an isolation test for a patch he's worked on.

Re: Injection points: preloading and runtime arguments

2024-06-06 Thread Andrey M. Borodin
> On 5 Jun 2024, at 03:52, Michael Paquier wrote: > > Another thing you could do is to define a > INJECTION_POINT_LOAD() in the code path you're stressing outside the > critical section where the point is run. This should save from a call > to the SQL function. This choice is up to the one

Re: Injection points: preloading and runtime arguments

2024-06-04 Thread Michael Paquier
On Tue, May 21, 2024 at 04:29:54PM +0500, Andrey M. Borodin wrote: > Currently I'm working on the test using this > $creator->query_until(qr/start/, q( > \echo start > select injection_points_wakeup(''); > select test_create_multixact(); > )); > > I'm fine if instead of injection_point

Re: Injection points: preloading and runtime arguments

2024-05-21 Thread Andrey M. Borodin
> On 21 May 2024, at 06:31, Michael Paquier wrote: > > So I agree that 0002 ought to call injection_init_shmem() when calling > injection_points_preload(), but it also seems to me that the test is > missing the fact that it should heat the backend cache to avoid the > allocations in the critic

Re: Injection points: preloading and runtime arguments

2024-05-20 Thread Michael Paquier
On Mon, May 20, 2024 at 05:01:15PM +0500, Andrey M. Borodin wrote: > Both features look useful to me. > I've tried to rebase my test of CV sleep during multixact generation[0]. I > used it like this: > > INJECTION_POINT_PRELOAD("GetNewMultiXactId-done"); > multi = GetNewMultiXactId(nmembe

Re: Injection points: preloading and runtime arguments

2024-05-20 Thread Andrey M. Borodin
> On 20 May 2024, at 17:01, Andrey M. Borodin wrote: Ugh, accidentally send without attaching the patch itself. Sorry for the noise. Best regards, Andrey Borodin. 0001-Add-multixact-CV-sleep.patch Description: Binary data

Re: Injection points: preloading and runtime arguments

2024-05-20 Thread Andrey M. Borodin
Hi! > On 20 May 2024, at 08:18, Michael Paquier wrote: Both features look useful to me. I've tried to rebase my test of CV sleep during multixact generation[0]. I used it like this: INJECTION_POINT_PRELOAD("GetNewMultiXactId-done"); multi = GetNewMultiXactId(nmembers, &offset); // star

Injection points: preloading and runtime arguments

2024-05-19 Thread Michael Paquier
Hi all, I have a couple of extra toys for injection points in my bucket that I'd like to propose for integration in v18, based on some feedback I have received: 1) Preload an injection point into the backend-level cache without running it. This has come up because an injection point run for the f