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 |
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 |