On Mon, Jun 5, 2023 at 09:30:28PM +0300, Heikki Linnakangas wrote: > If one process writes over shared memory that it shouldn't, it can cause a > crash in that process or some other process that reads it. Same with > multiple threads, no difference there. > > With a single process, one thread can modify another thread's "backend > private" memory, and cause the other thread to crash. Perhaps that's what > you meant? > > In practice, I don't think it's so bad. Even in a multi-threaded > environment, common bugs like buffer overflows and use-after-free are still > much more likely to access memory owned by the same thread, thanks to how > memory allocators work. And a completely random memory access is still more > likely to cause a segfault than corrupting another thread's memory. And > tools like CLOBBER_FREED_MEMORY/MEMORY_CONTEXT_CHECKING and valgrind are > pretty good at catching memory access bugs at development time, whether it's > multiple processes or threads.
I remember we used to have macros we called before we modified critical parts of shared memory, and if a process exited while in those blocks, the server would restart. Unfortunately, I can't find that in the code now. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.