| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Our naming of wait events is a disaster. |
| Date: | 2020-05-14 18:54:42 |
| Message-ID: | 11332.1589482482@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2020-05-14 19:03:57 | Re: new heapcheck contrib module |
| Previous Message | Robert Haas | 2020-05-14 18:52:06 | Re: SLRU statistics |