Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qM9Yn-001Wvo-Ch for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jul 2023 15:57:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qM9Yl-007Hrt-6g for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jul 2023 15:57:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qM9Yk-007Hrh-Pe for pgsql-hackers@lists.postgresql.org; Wed, 19 Jul 2023 15:57:50 +0000 Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qM9Yc-000TCy-1u for pgsql-hackers@lists.postgresql.org; Wed, 19 Jul 2023 15:57:49 +0000 Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-1b06777596cso5578753fac.2 for ; Wed, 19 Jul 2023 08:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neon-tech.20221208.gappssmtp.com; s=20221208; t=1689782261; x=1692374261; h=in-reply-to:references:subject:cc:from:to:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZMzn+A8XHo+bOgfSHzRk0UP20dZVRYUGOhmwwUTn3wY=; b=Ox4GvwBCOc0I2ylVg7a3QelX0Lk+cvkZvefBOngEefidEin31EajNf9w75gz57XKNV Sr3hemRM4pQPVjuzebahcN2MoF8NcHKBgulkvbWi3NUVX+4qujeN+/7rydQQ7OpU4a0W EM8NlpxMHfDg+4CRaaCuNiypTsSOA393s+VxESCEWe5FFKLcXHzjt4qo1SE/Apv89/JA JlcSbm3FQx6+XOGalM+mrv6fJnyIYKo1TNhoolW2nAIGbFF8UfWrTW2jEEHjnU4lvBL3 EbcTIP/qjGQUQxm9AdUQJEnZRIolmKwl6K2rGlRNkC/nQHNxzR0/slIGq5d8aINVqQTT YCcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689782261; x=1692374261; h=in-reply-to:references:subject:cc:from:to:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=ZMzn+A8XHo+bOgfSHzRk0UP20dZVRYUGOhmwwUTn3wY=; b=d6bTvNcKibVz5usWXvO6c8e64Ybtfq2cGwZRvGF5O9FSdseBBoNw0UaDe0HmuKeJeN b/kNx2EB1D2+BBuR0QciA4qxOTKyt9Rp8Qd9WcusPUq3GXkPZ2od5K5u9i4iyGXpsJv4 CtlNfCNckvhuMA+zKet7G7+JQ9VGVU6zGCCZb8BdHubMEjcZJOyBF1Ww+DSCOpsf/wrv ExCyz3JnsSbxVIZWVs2JtWMNlNcfcyzkb3wVmkYBUJo263RQ2nAyF5A33rdXLOuyXfri xKZozfHZnrGLa5zHlM/MFxC03exQUkWcN2JlvvjEakB/ItNtIcWzm82nqtqfFMCUY/w9 ruKA== X-Gm-Message-State: ABy/qLbPKOvTxRPcc/NZwtHM7qb4810VDiFeD823Z1YM8KimIf6BVC0S 3rcanmoP9LDYe98D4Zg1ptx3RH8g62WT13q6eCs= X-Google-Smtp-Source: APBJJlFUniSe1C1DFmPANu2UKtYWTBwb/GmC0DZsmnl6s+a8QiC01vmUgFoB2/bRVOu8KLtFyglk5g== X-Received: by 2002:a05:6870:e243:b0:1b0:39bc:857b with SMTP id d3-20020a056870e24300b001b039bc857bmr17442170oac.16.1689782261039; Wed, 19 Jul 2023 08:57:41 -0700 (PDT) Received: from localhost ([2607:fb90:f280:130d:3996:e070:71ee:42fb]) by smtp.gmail.com with ESMTPSA id a7-20020a056870374700b001ba72480f2fsm2045575oak.43.2023.07.19.08.57.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jul 2023 08:57:40 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; format=Flowed Date: Wed, 19 Jul 2023 10:57:39 -0500 Message-Id: To: "Masahiro Ikeda" , "Michael Paquier" , From: "Tristan Partin" Cc: Subject: Re: Support to define custom wait events for extensions X-Mailer: aerc 0.15.2-105-g00bf476582f7 References: <135feae32cd28f9fb555fe46acb939a0@oss.nttdata.com> <97449ae1a3b2189934890f6d78b18216@oss.nttdata.com> In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thanks for continuing to work on this patchset. I only have prose-related comments. > To support custom wait events, it add 2 APIs to define new wait events > for extensions dynamically. Remove the "it" here. > The APIs are > * WaitEventExtensionNew() > * WaitEventExtensionRegisterName() =20 > These are similar to the existing LWLockNewTrancheId() and > LWLockRegisterTranche(). This sentence seems like it could be removed given the API names have changed during the development of this patch. > First, extensions should call WaitEventExtensionNew() to get one > or more new wait event, which IDs are allocated from a shared > counter. Next, each individual process can use the wait event with > WaitEventExtensionRegisterName() to associate that a wait event > string to the associated name. This portion of the commit message is a copy-paste of the function comment. Whatever you do in the function comment (which I commented on below), just do here as well. > + so an wait event might be reported as just extensio= n > + rather than the extension-assigned name. s/an/a > + > + Custom Wait Events for Add-ins This would be the second use of "Add-ins" ever, according to my search. Should this be "Extensions" instead? > + > + Add-ins can define custom wait events that the wait event type is s/that/where > + Extension. > + > + > + First, add-ins should get new one or more wait events by calling: "one or more" doesn't seem to make sense grammatically here. > + > + uint32 WaitEventExtensionNew(void) > + > + Next, each individual process can use them to associate that Remove "that". > + a wait event string to the associated name by calling: > + > + void WaitEventExtensionRegisterName(uint32 wait_event_info, const ch= ar *wait_event_name); > + > + An example can be found in > + src/test/modules/test_custom_wait_events/test_custom_wait_= events.c > + in the PostgreSQL source tree. > + > + > + * Register a dynamic wait event name for extension in the lookup table > + * of the current process. Inserting an "an" before "extension" would make this read better. > +/* > + * Return the name of an wait event ID for extension. > + */ s/an/a > + /* > + * It's an user-defined wait event, so look in WaitEventExtension= Names[]. > + * However, it's possible that the name has never been registered= by > + * calling WaitEventExtensionRegisterName() in the current proces= s, in > + * which case give up and return "extension". > + */ s/an/a "extension" seems very similar to "Extension". Instead of returning a string here, could we just error? This seems like a programmer error on the part of the extension author. > + * Extensions can define their wait events. First, extensions should cal= l > + * WaitEventExtensionNew() to get one or more wait events, which IDs are > + * allocated from a shared counter. Next, each individual process can u= se > + * them with WaitEventExtensionRegisterName() to associate that a wait > + * event string to the associated name. An "own" before "wait events" in the first sentence would increase clarity. "where" instead of "which" in the next sentence. Remove "that" after "associate" in the third sentence. --=20 Tristan Partin Neon (https://neon.tech)