Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)
Date
Msg-id 2832831.1602276422@sss.pgh.pa.us
Whole thread Raw
In response to Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)  (Ranier Vilela <ranier.vf@gmail.com>)
List pgsql-hackers
Ranier Vilela <ranier.vf@gmail.com> writes:
> The trap is not on the second part of expression. Is in the first.
> If the pointer is NULL, ExecCopySlot will be called.

Your initial comment indicated that you were worried about
IncrementalSortState's group_pivot slot, but that is never going
to be null in any execution function of nodeIncrementalSort.c,
because ExecInitIncrementalSort always creates it.

(The test whether it's NULL in ExecReScanIncrementalSort therefore
seems rather useless and misleading, but it's not actually a bug.)

The places that use TupIsNull are just doing so because that's
the standard way to check whether a slot is empty.  The null
test inside the macro is pointless in this context (and in a lot
of its other use-cases, too) but we don't worry about that.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Next
From: Ranier Vilela
Date:
Subject: Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)