From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | ranier(dot)vf(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Possible dereference after null check (src/backend/executor/ExecUtils.c) |
Date: | 2021-02-12 06:28:01 |
Message-ID: | 20210212.152801.1280542156314557027.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 10 Feb 2021 19:54:46 -0300, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote in
> Hi,
>
> Per Coverity.
>
> The functions ExecGetInsertedCols and ExecGetUpdatedCols at ExecUtils.c
> only are safe to call if the variable "ri_RangeTableIndex" is != 0.
>
> Otherwise a possible Dereference after null check (FORWARD_NULL) can be
> raised.
As it turns out, it's a false positive. And perhaps we don't want to
take action just to satisfy the static code analyzer.
The coment in ExecGetInsertedCols says:
> /*
> * The columns are stored in the range table entry. If this ResultRelInfo
> * doesn't have an entry in the range table (i.e. if it represents a
> * partition routing target), fetch the parent's RTE and map the columns
> * to the order they are in the partition.
> */
> if (relinfo->ri_RangeTableIndex != 0)
> {
This means that any one of the two is always usable here. AFAICS,
actually, ri_RangeTableIndex is non-zero for partitioned (=leaf) and
non-partitoned relations and ri_RootResultRelInfo is non-null for
partitioned (parent or intermediate) relations (since they don't have
a coressponding range table entry).
The only cases where both are 0 and NULL are trigger-use, which is
unrelated to the code path.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | tsunakawa.takay@fujitsu.com | 2021-02-12 06:30:50 | RE: Parallel INSERT (INTO ... SELECT ...) |
Previous Message | Kyotaro Horiguchi | 2021-02-12 06:24:34 | Re: Is Recovery actually paused? |