postgres.git / summary / log / commit / refs

commit    d59ff4ab3111f20054425d82dab1393101dcfe8e
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Fri Feb 02 23:32:05 2018 +0000
First released in: master (reverted before release)
Reverted by: 05d0f13f0701 (in 11.0)

    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 c26b8ea44e3..70553b8fdf9 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;
 }
 
 /*


[parent: 957ff087c822]