From: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Weird test mixup |
Date: | 2024-05-02 08:33:45 |
Message-ID: | 99D1FBCA-6EA7-4BD0-922B-924A36D65183@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 2 May 2024, at 12:27, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote:
>> While writing an injection point test, I encountered a variant of the race
>> condition that f4083c4 fixed. It had three sessions and this sequence of
>> events:
>>
>> s1: local-attach to POINT
>> s2: enter InjectionPointRun(POINT), yield CPU just before injection_callback()
>> s3: detach POINT, deleting the InjectionPointCondition record
>> s2: wake up and run POINT as though it had been non-local
>
> Fun. One thing I would ask is why it makes sense to be able to detach
> a local point from a different session than the one who defined it as
> local. Shouldn't the operation of s3 be restricted rather than
> authorized as a safety measure, instead?
That seems to prevent meaningful use case. If we want exactly one session to be waiting just before some specific point, the only way to achieve this is to create local injection point. But the session must be resumable from another session.
Without this local waiting injection points are meaningless.
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-05-02 08:43:58 | Re: Weird test mixup |
Previous Message | Yuya Watari | 2024-05-02 07:56:41 | Re: [PoC] Reducing planning time when tables have many partitions |