Re: Our naming of wait events is a disaster.

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-05-12T23:41:19Z
Lists: pgsql-hackers
For the specific category of the heavyweight lock types, I'm
now thinking that we can't change the event names very much, because
those are also exposed in pg_locks' locktype column.  We can be
darn certain, for example, that changing the spelling of "relation"
in that column would break a lot of user queries.  Conceivably we
could decouple the wait event names from the locktype column, but
on the whole that doesn't seem like a great plan.

However, having said that, I remain on the warpath about "speculative
token".  That's an utterly horrid choice for both locktype and wait
event.  I also notice, with no amusement, that "speculative token"
is not documented in the pg_locks documentation.  So I think we should
change it ... but to what, exactly?  Looking at the other existing names:

const char *const LockTagTypeNames[] = {
	"relation",
	"extend",
	"page",
	"tuple",
	"transactionid",
	"virtualxid",
	"speculative token",
	"object",
	"userlock",
	"advisory"
};

I'm inclined to propose "spectoken".  I'd be okay with "spec_token" as
well, but there are not underscores in the longer-established names.

(Needless to say, this array is going to gain a comment noting that
there are two places to document any changes.  Also, if we split up
the wait_event table as discussed earlier, it might make sense for
pg_locks' documentation to cross-reference the sub-table for heavyweight
lock events, since that has some explanation of what the codes mean.)

			regards, tom lane



Commits

  1. Mop-up for wait event naming issues.

  2. Change locktype "speculative token" to "spectoken".

  3. Drop the redundant "Lock" suffix from LWLock wait event names.

  4. Rename assorted LWLock tranches.

  5. Rename SLRU structures and associated LWLocks.

  6. Collect built-in LWLock tranche names statically, not dynamically.