From d59ff4ab3111f20054425d82dab1393101dcfe8e Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 2 Feb 2018 18:32:05 -0500 Subject: [PATCH] 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. --- src/backend/executor/nodeHash.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/backend/executor/nodeHash.c b/src/backend/executor/nodeHash.c index c26b8ea44e..70553b8fdf 100644 --- 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; } /* -- 2.40.0