Re: Table AM Interface Enhancements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Table AM Interface Enhancements
Date: 2024-04-01 16:36:43
Message-ID: 1092843.1711989403@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Coverity complained about what you did in RelationParseRelOptions
in c95c25f9a:

*** CID 1595992: Null pointer dereferences (FORWARD_NULL)
/srv/coverity/git/pgsql-git/postgresql/src/backend/utils/cache/relcache.c: 499 in RelationParseRelOptions()
493
494 /*
495 * Fetch reloptions from tuple; have to use a hardwired descriptor because
496 * we might not have any other for pg_class yet (consider executing this
497 * code for pg_class itself)
498 */
>>> CID 1595992: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "tableam" to "extractRelOptions", which dereferences it.
499 options = extractRelOptions(tuple, GetPgClassDescriptor(),
500 tableam, amoptsfn);
501

I see that extractRelOptions only uses the tableam argument for some
relkinds, and RelationParseRelOptions does set it up for those
relkinds --- but Coverity's complaint isn't without merit, because
those two switch statements are looking at *different copies of the
relkind*, which in theory could be different. This all seems quite
messy and poorly factored. Can't we do better? Why do we need to
involve two copies of allegedly the same pg_class tuple, anyhow?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2024-04-01 16:48:08 Re: Table AM Interface Enhancements
Previous Message Alvaro Herrera 2024-04-01 16:22:41 Re: Psql meta-command conninfo+