Em qua., 22 de mai. de 2024 às 13:09, Ranier Vilela <ranier...@gmail.com> escreveu:
> Em qua., 22 de mai. de 2024 às 11:44, Ranier Vilela <ranier...@gmail.com> > escreveu: > >> Hi. >> >> Per Coverity. >> >> 2. returned_null: SearchSysCacheAttName returns NULL (checked 20 out of >> 21 times). >> 3. var_assigned: Assigning: ptup = NULL return value from >> SearchSysCacheAttName. >> 964 ptup = SearchSysCacheAttName(relid, attname); >> CID 1545986: (#1 of 1): Dereference null return value (NULL_RETURNS) >> 4. dereference: Dereferencing ptup, which is known to be NULL. >> >> The functions SearchSysCacheAttNum and SearchSysCacheAttName, >> need to have the result checked. >> >> The commit 5091995 >> <https://github.com/postgres/postgres/commit/509199587df73f06eda898ae13284292f4ae573a>, >> left an oversight. >> >> Fixed by the patch attached, a change of style, unfortunately, was >> necessary. >> > v1 Attached, fix wrong column variable name in error report. > 1. Another concern is the function *get_partition_ancestors*, which may return NIL, which may affect *llast_oid*, which does not handle NIL entries. 2. Is checking *relispartition* enough? There a function *check_rel_can_be_partition* (src/backend/utils/adt/partitionfuncs.c), which performs a much more robust check, would it be worth using it? With the v2 attached, 1 is handled, but, in this case, will it be the most correct? best regards, Ranier Vilela
v2-fix-catalog-cache-search-check.patch
Description: Binary data
