Re: Support to define custom wait events for extensions

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Support to define custom wait events for extensions
Date: 2023-07-13 00:12:36
Message-ID: ZK9BdDI6KMxmiG+5@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 12, 2023 at 05:46:31PM +0900, Michael Paquier wrote:
> On Wed, Jul 12, 2023 at 04:52:38PM +0900, Masahiro Ikeda wrote:
>> If the behavior is unexpected, we need to change the current code.
>> I have created a patch for the areas that I felt needed to be changed.
>> - 0001-change-the-die-condition-in-generate-wait_event_type.patch
>> (In addition to the above, "$continue = ",\n";" doesn't appear to be
>> necessary.)
>
> die "wait event names must start with 'WAIT_EVENT_'"
> if ( $trimmedwaiteventname eq $waiteventenumname
> - && $waiteventenumname !~ /^LWLock/
> - && $waiteventenumname !~ /^Lock/);
> - $continue = ",\n";
> + && $waitclassname !~ /^WaitEventLWLock$/
> + && $waitclassname !~ /^WaitEventLock$/);
>
> Indeed, this looks wrong as-is. $waiteventenumname refers to the
> names of the enum elements, so we could just apply a filter based on
> the class names in full. The second check in for the generation of
> the c/h files uses the class names.

At the end, I have gone with an event simpler way and removed the
checks for LWLock and Lock as their hardcoded values marked as DOCONLY
satisfy this check. The second check when generating the C and header
code has also been simplified a bit to use an exact match with the
class name.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matheus Alcantara 2023-07-13 00:22:13 Duplicated LLVMJitHandle->lljit assignment?
Previous Message Vik Fearing 2023-07-13 00:03:26 Re: MERGE ... RETURNING