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 1rLnGy-000T4F-6r for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jan 2024 16:42:16 +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 1rLnGx-001j1I-1P for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jan 2024 16:42:15 +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 1rLnGw-001j19-O7 for pgsql-hackers@lists.postgresql.org; Fri, 05 Jan 2024 16:42:14 +0000 Received: from mail-il1-x132.google.com ([2607:f8b0:4864:20::132]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rLnGp-0001AH-QN for pgsql-hackers@postgresql.org; Fri, 05 Jan 2024 16:42:14 +0000 Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-3606f507efeso2964585ab.3 for ; Fri, 05 Jan 2024 08:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704472926; x=1705077726; darn=postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=wBYswiztQSu7ov8szDjV36fIPgLWiBebut81X3Aramc=; b=V5V2TrJZ1mphZ3NKGTPntDy0BnVCQGqpoMnRknRAb6PmyUC9msC6cfzuB4r9K+NKok I4Tlc3DcfBeDNApzt9C3PfploGZwaMcFvVk7fYN2vc6us/YWUV8KyLnQ3onXz3ScRLxx VjTNsWaqf3K4BG80lEAWhcoExUOAcQSsO22xzpwDvB1+hk+uaShQ6rWtjhsXDeLFNl6h NqXVjgllj85LlDLkQ6s7+TnJvjtjDCbOc3LqMmscHhZ08T7wXdpqNjcYN1dC6MndRdWb ytx0FUBE9ttdDlzJCVWP/vkIJFiPw8Mk4ZYzybRWtRL110UG8MU4q/50udSnm7f2I7Lf ArpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704472926; x=1705077726; h=in-reply-to: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=wBYswiztQSu7ov8szDjV36fIPgLWiBebut81X3Aramc=; b=XT55wd1CypzknCJEr+DL1wpY8Nj7i0DZ5A0NkNsPM0D4shDL/U1+YmLS2AnFj0OtvX 852YSF8uVP70A35ljdKO41994LSxLwyk63A1/aB+WkYNGMT4PAaDa+cBGlTeahM93boK 7BfQkpkVCyrL7BW8wBSuzE6icC0W22nKYGHL8STqVxqCisJJR2czuB1sLXGp5uxna/uB nwydZFFl8U3mYa/XYQ5GWt5IJyynmCnbviq1SvuBV1XcY3PRAi0B4eMFSQUmW17RYK3M fkBC/HeWWHWCQrZubZ1Rmkgsww9WXhxlxN/b/tb7RgMk9o2M244SpGaCnXusUmtEJo42 ClMQ== X-Gm-Message-State: AOJu0YygZEBJgzTgrDniT+NE2oGvmzjs4bBvj9yK8HUskirRnUiPhP9m NEAJEoj+CustkLt/WKz/Ajw= X-Google-Smtp-Source: AGHT+IFoNnEgy2l5eeyg02XU4kS1ebGy3aJcq+zNtYTfVDbjHzeoz06Xg5suwOXYHE93x2i1pJvQ4Q== X-Received: by 2002:a05:6e02:1aa6:b0:35d:6121:3794 with SMTP id l6-20020a056e021aa600b0035d61213794mr2501067ilv.54.1704472926042; Fri, 05 Jan 2024 08:42:06 -0800 (PST) Received: from nathanxps13 (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id h13-20020a92d08d000000b003600c155f7dsm593009ilh.41.2024.01.05.08.42.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jan 2024 08:42:05 -0800 (PST) Date: Fri, 5 Jan 2024 10:42:03 -0600 From: Nathan Bossart To: Bertrand Drouvot Cc: Robert Haas , "pgsql-hackers@postgresql.org" , Michael Paquier Subject: Re: verify predefined LWLocks have entries in wait_event_names.txt Message-ID: <20240105164203.GC2168314@nathanxps13> References: <20240102173120.GA1061678@nathanxps13> <20240102214544.GA1063425@nathanxps13> <20240105061144.GA2166447@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thanks for reviewing. On Fri, Jan 05, 2024 at 07:39:39AM +0000, Bertrand Drouvot wrote: > Another option could be to create a sub-section for predefined LWLocks that are > part of lwlocknames.txt and then sort both list (the one in the sub-section and > the one in lwlocknames.txt). That would avoid the "must be listed in the same order" > constraint. That said, I think the way it is done in the patch is fine because > if one does not follow the constraint then the build would fail. IMHO the ordering constraint makes it easier for humans to verify the lists match. > + die "lists of predefined LWLocks in lwlocknames.txt and wait_event_names.txt do not match" > + unless $wait_event_lwlocks[$i] eq $lockname; > > What about printing $wait_event_lwlocks[$i] and $lockname in the error message? > Something like? > > " > die "lists of predefined LWLocks in lwlocknames.txt and wait_event_names.txt do not match (comparing $lockname and $wait_event_lwlocks[$i])" > unless $wait_event_lwlocks[$i] eq $lockname; > " > > I think that would give more clues for debugging purpose. Sure, I'll add something like that. I think this particular scenario is less likely, but that's not a reason to make the error message hard to decipher. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com