From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | ranier_gyn(at)hotmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH][BUG_FIX] Potential null pointer dereferencing. |
Date: | 2019-11-13 01:43:35 |
Message-ID: | 20191113.104335.1975009222845696755.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Tue, 12 Nov 2019 14:03:53 +0000, Ranier Vilela <ranier_gyn(at)hotmail(dot)com> wrote in
> Hi,
> The condition is :
> 74. if (TupIsNull(slot)) is true
> 85. if (TupIsNull(resultTupleSlot)) is true too.
See the definition of TupIsNull. It checks the tupleslot at a valid
pointer is EMPTY as well. And node->ps.ps_ResultTupleSlot cannot be
NULL there since ExecInitUnique initializes it. The sequence is
obvious so even Assert is not needed there, I think.
> If resultTupleSlot is not can be NULL, why test if (TupIsNull(resultTupleSlot))?
It checks if there is no stored "previous" tuple, which is used to
detect the next value. If it is EMPTY (not NULL), it is the first
tuple from the outerPlan as described in the comment just above.
> Occurring these two conditions ExecClearTuple is called, but, don't check by NULL arg.
>
> There are at least 2 more possible cases, envolving ExecClearTuple:
> nodeFunctionscan.c and nodeWindowAgg.c
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2019-11-13 01:52:52 | Re: [PATCH] Do not use StdRdOptions in Access Methods |
Previous Message | Kyotaro Horiguchi | 2019-11-13 01:25:47 | Re: Why overhead of SPI is so large? |