Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)

Em sáb., 10 de out. de 2020 às 00:11, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> escreveu:

> On Fri, Oct 9, 2020 at 6:41 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
>
>> The problem is not only in nodeIncrementalSort.c, but in several others
>> too, where people are using TupIsNull with ExecCopySlot.
>> I would call this a design flaw.
>> If (TupIsNull)
>> ExecCopySlot
>>
>> The callers, think they are using TupIsNotNullAndEmpty.
>> If (TupIsNotNullAndEmpty)
>> ExecCopySlot
>>
>
> IMO both names are problematic, too data value centric, not semantic.
> TupIsValid for the name and negating the existing tests would help to at
> least clear that part up. Then, things operating on invalid tuples would
> be expected to know about both representations. In the case of
> ExecCopySlot there is nothing it can do with a null representation of an
> invalid tuple so it would have to fail if presented one. An assertion
> seems sufficient.
>
IHMO, assertion it is not the solution.

Steven suggested looking for some NULL pointer font above the calls.
I say that it is not necessary, there is no NULL pointer.
Whoever guarantees this is the combination, which for me is an assertion.

If (TupIsNull)
ExecCopySlot

It works as a subject, but in release mode.
It is the equivalent of:

If (TupIsNull)
Abort

The only problem for me is that we are running this assertion on the
clients' machines.

regards,
Ranier Vilela

>