Re: Use an enum for RELKIND_*?

From: Greg Stark <stark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Use an enum for RELKIND_*?
Date: 2018-12-21 22:16:05
Message-ID: CAM-w4HNokh9goZUhuzG-Gi5fHT-AmyKgS-a4p=GqzmJwaD4rmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Out of curiosity I built with -Wswitch-enum to see if it would be
possible to just enable it. It looks like the main culprits are the
node types and if those were switched to #defines it might be feasible
to do so though it would still be a lot of hassle to add case labels
all over the place.

But I had a second look to see if the output pointed out any actual
bugs. I found one though it's pretty minor:

lockfuncs.c:234:3: warning: enumeration value
‘LOCKTAG_SPECULATIVE_TOKEN’ not handled in switch [-Wswitch-enum]
switch ((LockTagType) instance->locktag.locktag_type)
^~~~~~

It just causes speculative locks to be printed wrong in the
pg_lock_status view. And speculative locks are only held transiently
so unless you're do a bulk load using ON CONFLICT (and also cared
about pg_lock_status, perhaps in some monitoring tool) you wouldn't
even notice this:

postgres***=# select * from pg_lock_status() where locktype =
'speculative token';
┌───────────────────┬──────────┬──────────┬──────┬───────┬────────────┬───────────────┬─────────┬───────┬──────────┬────────────────────┬───────┬───────────────┬─────────┬──────────┐
│ locktype │ database │ relation │ page │ tuple │ virtualxid
│ transactionid │ classid │ objid │ objsubid │ virtualtransaction │
pid │ mode │ granted │ fastpath │
├───────────────────┼──────────┼──────────┼──────┼───────┼────────────┼───────────────┼─────────┼───────┼──────────┼────────────────────┼───────┼───────────────┼─────────┼──────────┤
│ speculative token │ 634 │ │ │ │
│ │ 1 │ 0 │ 0 │ 4/32 │
18652 │ ExclusiveLock │ t │ f │
└───────────────────┴──────────┴──────────┴──────┴───────┴────────────┴───────────────┴─────────┴───────┴──────────┴────────────────────┴───────┴───────────────┴─────────┴──────────┘

The speculative lock is actually on a transaction ID and "speculative
lock token" so the "database", "objid", and "objsubid" are bogus here.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2018-12-21 22:19:27 Re: Compiling on Termux
Previous Message David Rowley 2018-12-21 21:57:00 Re: [HACKERS] ArrayLists instead of List (for some things)