Re: MultiXact\SLRU buffers configuration - Mailing list pgsql-hackers

From Andrey M. Borodin
Subject Re: MultiXact\SLRU buffers configuration
Date
Msg-id 0925F9A9-4D53-4B27-A87E-3D83A757B0E0@yandex-team.ru
Whole thread Raw
In response to Re: MultiXact\SLRU buffers configuration  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
Responses Re: MultiXact\SLRU buffers configuration
Re: MultiXact\SLRU buffers configuration
List pgsql-hackers

> On 28 Jan 2024, at 23:17, Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
>
>
>> Perhaps a test to make the code reach the usleep(1000) can be written
>> using injection points (49cd2b93d7db)?
>
> I've tried to prototype something like that. But interesting point between GetNewMultiXactId() and
RecordNewMultiXact()is a critical section, and we cannot have injection points in critical sections... 
> Also, to implement such a test we need "wait" type of injection points, see step 2 in attachment. With this type of
injectionpoints I can stop a backend amidst entering information about new MultiXact. 

Here's the test draft. This test reliably reproduces sleep on CV when waiting next multixact to be filled into
"members"SLRU. 
Cost of having this test:
1. We need a new injection point type "wait" (in addition to "error" and "notice"). It cannot be avoided, because we
needto sync at least 3 processed to observe condition we want. 
2. We need new way to declare injection point that can happen inside critical section. I've called it "prepared
injectionpoint". 

Complexity of having this test is higher than complexity of CV-sleep patch itself. Do we want it? If so I can produce
cleanerversion, currently all multixact tests are int injection_points test module. 


Best regards, Andrey Borodin.

Attachment

pgsql-hackers by date:

Previous
From: Julien Riou
Date:
Subject: Re: PROXY protocol support
Next
From: Corey Huinker
Date:
Subject: Re: Document efficient self-joins / UPDATE LIMIT techniques.