> 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
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
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
> 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
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
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
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
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
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
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
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
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
> 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
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.
> 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
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
> 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
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
> 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
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
20 matches
Mail list logo
