On Mon, Jun 5, 2023 at 5:15 PM Bruce Momjian <br...@momjian.us> wrote: > > Isn't that what we call a critical section? They effectively "promote" > > any ERROR (e.g., from an OOM) into a PANIC.
> Yes, sorry, critical sections is what I was remembering. My question is > whether all unexpected backend exits should be treated as critical > sections? I think that it boils down to this: critical sections help us to avoid various inconsistencies that might otherwise be introduced to critical state, usually in shared memory. And so critical sections are mostly about protecting truly crucial state, even in the presence of irrecoverable problems (e.g., those caused by corruption that was missed before the critical section was reached, fsync() reporting failure on recent Postgres versions). This is mostly about the state itself -- it's not about cleaning up from routine errors at all. The server isn't supposed to PANIC, and won't unless some fundamental assumption that the system makes isn't met. I said that an OOM could cause a PANIC. But that really shouldn't be possible in practice, since it can only happen when code in a critical section actually attempts to allocate memory in the first place. There is an assertion in palloc() that will catch code that violates that rule. It has been known to happen from time to time, but theoretically it should never happen. Discussion about the robustness of threads versus processes seems to only be concerned with what can happen after something "impossible" takes place. Not before. Backend code is not supposed to corrupt memory, whether shared or local, with or without threads. Code in critical sections isn't supposed to even attempt memory allocation. Jeremy and others have suggested that processes have significant robustness advantages. Maybe they do, but it's hard to say either way because these benefits only apply "when the impossible happens". In any given case it's reasonable to wonder if the user was protected by our multi-process architecture, or protected by dumb luck. Could even be both. -- Peter Geoghegan
