Fix another instance of unsafe coding for shm_toc_lookup failure.

One or another author of commit 5bcf389ec seems to have thought that
computing an offset from a NULL pointer would yield another NULL pointer.
There may possibly be architectures where that works, but common machines
don't work like that.  Per a quick code review of places calling
shm_toc_lookup and not using noError = false.

diff --git a/src/backend/executor/nodeHash.c b/src/backend/executor/nodeHash.c
index c26b8ea44e33d7079ea4581bf0261889cc90b63e..70553b8fdf97ed1aaec2fe510345279fa40bcbef 100644 (file)
--- a/src/backend/executor/nodeHash.c
+++ b/src/backend/executor/nodeHash.c
@@ -2582,9 +2582,13 @@ ExecHashInitializeWorker(HashState *node, ParallelWorkerContext *pwcxt)
 {
        SharedHashInfo *shared_info;
 
+       /* might not be there ... */
        shared_info = (SharedHashInfo *)
                shm_toc_lookup(pwcxt->toc, node->ps.plan->plan_node_id, true);
-       node->hinstrument = &shared_info->hinstrument[ParallelWorkerNumber];
+       if (shared_info)
+               node->hinstrument = &shared_info->hinstrument[ParallelWorkerNumber];
+       else
+               node->hinstrument = NULL;
 }
 
 /*