]> granicus.if.org Git - postgresql/commit
Don't be so trusting that shm_toc_lookup() will always succeed.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 5 Jun 2017 16:05:42 +0000 (12:05 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 5 Jun 2017 16:05:42 +0000 (12:05 -0400)
commitd4663350646ca0c069a36d906155a0f7e3372eb7
tree0bc14a79fae8af098aeea21b7a018cf220c02a6e
parentaf51fea039bb8e00066d68d919312df1701dc03e
Don't be so trusting that shm_toc_lookup() will always succeed.

Given the possibility of race conditions and so on, it seems entirely
unsafe to just assume that shm_toc_lookup() always finds the key it's
looking for --- but that was exactly what all but one call site were
doing.  To fix, add a "bool noError" argument, similarly to what we
have in many other functions, and throw an error on an unexpected
lookup failure.  Remove now-redundant Asserts that a rather random
subset of call sites had.

I doubt this will throw any light on buildfarm member lorikeet's
recent failures, because if an unnoticed lookup failure were involved,
you'd kind of expect a null-pointer-dereference crash rather than the
observed symptom.  But you never know ... and this is better coding
practice even if it never catches anything.

Discussion: https://postgr.es/m/9697.1496675981@sss.pgh.pa.us
src/backend/access/transam/parallel.c
src/backend/executor/execParallel.c
src/backend/executor/nodeBitmapHeapscan.c
src/backend/executor/nodeCustom.c
src/backend/executor/nodeForeignscan.c
src/backend/executor/nodeIndexonlyscan.c
src/backend/executor/nodeIndexscan.c
src/backend/executor/nodeSeqscan.c
src/backend/storage/ipc/shm_toc.c
src/include/storage/shm_toc.h
src/test/modules/test_shm_mq/worker.c