mirror of
https://github.com/postgres/postgres.git
synced 2025-11-26 23:43:30 +03:00
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
This commit is contained in:
@@ -32,7 +32,7 @@ extern shm_toc *shm_toc_attach(uint64 magic, void *address);
|
||||
extern void *shm_toc_allocate(shm_toc *toc, Size nbytes);
|
||||
extern Size shm_toc_freespace(shm_toc *toc);
|
||||
extern void shm_toc_insert(shm_toc *toc, uint64 key, void *address);
|
||||
extern void *shm_toc_lookup(shm_toc *toc, uint64 key);
|
||||
extern void *shm_toc_lookup(shm_toc *toc, uint64 key, bool noError);
|
||||
|
||||
/*
|
||||
* Tools for estimating how large a chunk of shared memory will be needed
|
||||
|
||||
Reference in New Issue
Block a user