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 1rKmaF-004TYo-Hu for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jan 2024 21:45:59 +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 1rKmaD-001hEt-62 for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jan 2024 21:45:57 +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 1rKmaC-001hEk-Q2 for pgsql-hackers@lists.postgresql.org; Tue, 02 Jan 2024 21:45:56 +0000 Received: from mail-il1-x129.google.com ([2607:f8b0:4864:20::129]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rKma5-00FDjV-OP for pgsql-hackers@postgresql.org; Tue, 02 Jan 2024 21:45:56 +0000 Received: by mail-il1-x129.google.com with SMTP id e9e14a558f8ab-35fe8245d0eso34798105ab.0 for ; Tue, 02 Jan 2024 13:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704231947; x=1704836747; darn=postgresql.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=mW6z+HXSLdVXw47ufv56zQAHNYVRMo5/d4aCSTPYiwM=; b=imOSuZ4Op1HAxSeqAJEmXmNS0apx/Q0aGp6Jl1cGObkKISwyUY/URtoTH6YEb9HwTq uvVj4DZxLnai1ywYXf/M0VB/A16dHlCOSMmejFLMz27777lpUOBMlfwNHrOPQ7z6NzS/ mSfW8viFlulvjSKeg9Q6Nje/JNnHNaII3jRWZHwDPB7lsTqWtNm4wOZI8mGjHc2tYQFk SHdDIzxwkYise8fOpftqQKnOkZy55hEBIJ+ZQvbcVZojUC1Zrg/Wxltb7FrYZEKVXdM4 1z/GVuWrQK8A2mNoeW5aFiAiU79SOA8QoiEsHReV5j2oOI1ZZAgVSIaQg12AUuZUKa2z s5xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704231947; x=1704836747; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mW6z+HXSLdVXw47ufv56zQAHNYVRMo5/d4aCSTPYiwM=; b=ndueZ4CN6Er0DFuiUENgoMFfPq/c8y1Dyi5vhBaX7ZHPR/AeeQ7UDP1JdivQ8cMLjG lfrZIk1UYbXgss/gzlaRgriOLn7FMwozbemAXEd+cnwiU+ooKG18Kql5veQtPnLesEWx 2UOM6wGOlcjXyN4ixSZUsWtREguEHPSqBNwUo0lj6AgPHRIQNMImmJPRB3zLaCLZuLRz s7mgzlpeexDLNI2mc5cIqiuEpV2vYnahuAylk7GIO9hdSTH+KXw7xKWHMvPiV3oymWBf VLKtXJdt5YtLYUNS5AMePzRBVdctcD7srBwileLaCGG/S/4mrjAIU3QFpJLBCtno347k atoA== X-Gm-Message-State: AOJu0YzA515KOKsEK1DG2qjgnSj+9VszjX5e2LBhCJFCvGqPgcI9qIXV 53/94KkcweIByPgmOpBhRmiFdDFDByQ= X-Google-Smtp-Source: AGHT+IF/mi0uIWo+9scxwjZzZ1VTk8pD4xvohHmU4pf5ebhtcDY11qMTpiPYGyjzeB1/DSz+pmsOuw== X-Received: by 2002:a05:6e02:1948:b0:360:17aa:7ce3 with SMTP id x8-20020a056e02194800b0036017aa7ce3mr14069981ilu.11.1704231947746; Tue, 02 Jan 2024 13:45:47 -0800 (PST) Received: from nathanxps13 (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id bb39-20020a0566383b2700b0046ce40d28a9sm7096765jab.105.2024.01.02.13.45.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 13:45:47 -0800 (PST) Date: Tue, 2 Jan 2024 15:45:44 -0600 From: Nathan Bossart To: Robert Haas Cc: "pgsql-hackers@postgresql.org" , Michael Paquier Subject: Re: verify predefined LWLocks have entries in wait_event_names.txt Message-ID: <20240102214544.GA1063425@nathanxps13> References: <20240102173120.GA1061678@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jan 02, 2024 at 01:13:16PM -0500, Robert Haas wrote: > On Tue, Jan 2, 2024 at 12:31 PM Nathan Bossart wrote: >> I think we're supposed to omit the "Lock" suffix in wait_event_names.txt. > > Ugh, sorry. But also, why in the world? That seems to date back to commit 14a9101. I can agree that the suffix is somewhat redundant since these are already marked as type "LWLock", but I'll admit I've been surprised by this before, too. IMHO it makes this proposed test more important because you can't just grep for a different lock to find all the places you need to update. > - Check in both directions instead of just one? > > - Verify ordering? To do those things, I'd probably move the test to one of the scripts that generates the documentation or header file (pg_wait_events doesn't tell us whether a lock is predefined or what order it's listed in). That'd cause failures at build time instead of during testing, which might be kind of nice, too. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com