| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c) |
| Date: | 2020-10-09 20:47:02 |
| Message-ID: | 2832831.1602276422@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Ranier Vilela <ranier(dot)vf(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ranier Vilela | 2020-10-09 20:50:09 | Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c) |
| Previous Message | Thomas Munro | 2020-10-09 20:39:15 | Re: Parallel INSERT (INTO ... SELECT ...) |