Re: Weird test mixup

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.

In response to

Responses

Browse pgsql-hackers by date

  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