Skip to content

Commit d59ff4a

Browse files
committed
Fix another instance of unsafe coding for shm_toc_lookup failure.
One or another author of commit 5bcf389 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.
1 parent 957ff08 commit d59ff4a

File tree

1 file changed

+5
-1
lines changed

1 file changed

+5
-1
lines changed

src/backend/executor/nodeHash.c

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2582,9 +2582,13 @@ ExecHashInitializeWorker(HashState *node, ParallelWorkerContext *pwcxt)
25822582
{
25832583
SharedHashInfo *shared_info;
25842584

2585+
/* might not be there ... */
25852586
shared_info = (SharedHashInfo *)
25862587
shm_toc_lookup(pwcxt->toc, node->ps.plan->plan_node_id, true);
2587-
node->hinstrument = &shared_info->hinstrument[ParallelWorkerNumber];
2588+
if (shared_info)
2589+
node->hinstrument = &shared_info->hinstrument[ParallelWorkerNumber];
2590+
else
2591+
node->hinstrument = NULL;
25882592
}
25892593

25902594
/*

0 commit comments

Comments
 (0)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy