pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Isaac Morland <isaac.morland@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Our naming of wait events is a disaster.
Date: Thu, 14 May 2020 14:54:42 -0400
Message-ID: <11332.1589482482@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmoZ8qOUCXGp5RC=Bc2Wo7AOSNKnru56yghfzu-X9O=7Vjw@mail.gmail.com>
References: <20200512202726.GA31125@alvherre.pgsql>
	<9871.1589321468@sss.pgh.pa.us>
	<CAMsGm5ci68RWekX+JCA9QJzoqBk0Q08rJa2akv0eR1mvpURA2w@mail.gmail.com>
	<5598.1589338488@sss.pgh.pa.us>
	<CA+TgmoZ8qOUCXGp5RC=Bc2Wo7AOSNKnru56yghfzu-X9O=7Vjw@mail.gmail.com>

Robert Haas <robertmhaas@gmail.com> 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





view thread (30+ messages)  latest in thread

Message-ID: <11332.1589482482@sss.pgh.pa.us>
Permalink:  ../11332.1589482482@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/11332.1589482482@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, isaac.morland@gmail.com, alvherre@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: Our naming of wait events is a disaster.
  In-Reply-To: <11332.1589482482@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox