Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jZJ0L-0007HK-KA for pgsql-hackers@arkaria.postgresql.org; Thu, 14 May 2020 18:54:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jZJ0K-0003hQ-Hi for pgsql-hackers@arkaria.postgresql.org; Thu, 14 May 2020 18:54:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jZJ0K-0003hJ-Ae for pgsql-hackers@lists.postgresql.org; Thu, 14 May 2020 18:54:48 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jZJ0I-0002G6-1p for pgsql-hackers@lists.postgresql.org; Thu, 14 May 2020 18:54:47 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id 04EIsgT1011333; Thu, 14 May 2020 14:54:42 -0400 From: Tom Lane To: Robert Haas cc: Isaac Morland , Alvaro Herrera , PostgreSQL Hackers Subject: Re: Our naming of wait events is a disaster. In-reply-to: References: <20200512202726.GA31125@alvherre.pgsql> <9871.1589321468@sss.pgh.pa.us> <5598.1589338488@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Thu, 14 May 2020 14:16:29 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11331.1589482482.1@sss.pgh.pa.us> Date: Thu, 14 May 2020 14:54:42 -0400 Message-ID: <11332.1589482482@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > I tend to prefer that modules register their own tranches rather than > having a central table someplace, because I like the idea that the > things that a particular module knows about are contained within its > own source files and not spread all over the code base. I think that > we've done rather badly with this in a number of places, lwlock.c > among them, and I don't like it much. Well, we could solve this problem very easily by ripping out everything having to do with wait-state monitoring ... and personally I'd be a lot in favor of that, because I haven't seen anything about either the design or documentation of the feature that I thought was very well done. However, if you'd like to have wait-state monitoring, and you'd like the documentation for it to be more useful than "go read the code", then I don't see any way around the conclusion that there are going to be centralized lists of the possible wait states. That being the case, refusing to use a centralized list in the implementation seems rather pointless; and having some aspects of the implementation use centralized lists (see the enums in lwlock.h and elsewhere) while other aspects don't is just schizophrenic. > In some sense, the lack of naming consistency here is > a manifestation of an underlying chaos in the code: we've created many > different ways of waiting for things with many different > characteristics and little thought to consistency, and this mechanism > has exposed that underlying problem. Yeah, agreed. Nonetheless, now we have a problem. regards, tom lane