Re: Our naming of wait events is a disaster.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Our naming of wait events is a disaster.
Date: 2020-05-14 01:29:25
Message-ID: 9056.1589419765@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The attached patch doesn't actually change any LWLock names, but it
is a useful start on that project. What it does is to get rid of the
current scheme of dynamically registering the names of built-in
LWLocks in favor of having a constant array of those names. It's
completely foolish to expend process-startup cycles on constructing
an array of constant data; moreover, the way things are done now
results in the tranche names being defined all over creation. I draw
a short straight line between that technique and the lack of consistency
in the tranche names. Given that we have an enum in lwlock.h enumerating
the built-in tranches, there's certainly no expectation that somebody's
going to create a new one without letting the lwlock module know about
it, so this gives up no flexibility. In fact, it adds some, because
we can now name an SLRU's buffer-locks tranche whatever we want ---
it's not hard-wired as being the same as the SLRU's base name.

The dynamic registration mechanism is still there, but it's now
*only* used if you load an extension that creates dynamic LWLocks.

At some point it might be interesting to generate the enum
BuiltinTrancheIds and the BuiltinTrancheNames array from a common
source file, as we do for lwlocknames.h/.c. I didn't feel a need
to make that happen today, though.

regards, tom lane

Attachment Content-Type Size
simplify-management-of-builtin-lwlocks.patch text/x-diff 14.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message godjan • 2020-05-14 02:18:33 Re: Strange decreasing value of pg_last_wal_receive_lsn()
Previous Message Kyotaro Horiguchi 2020-05-14 01:25:26 Re: MultiXact\SLRU buffers configuration