Re: Let's make PostgreSQL multi-threaded
От | Heikki Linnakangas |
---|---|
Тема | Re: Let's make PostgreSQL multi-threaded |
Дата | |
Msg-id | 9e8a5399-29da-e517-81c6-9b78d9c39804@iki.fi обсуждение исходный текст |
Ответ на | Re: Let's make PostgreSQL multi-threaded (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Let's make PostgreSQL multi-threaded
|
Список | pgsql-hackers |
On 05/06/2023 14:04, Bruce Momjian wrote: > On Mon, Jun 5, 2023 at 08:29:16PM +0300, Heikki Linnakangas wrote: >> I don't think there would be any new class of errors that would cause server >> restarts. In theory, having a separate address space for each backend gives >> you some protection. In practice, there are a lot of shared memory >> structures anyway that you can stomp over, and a segfault or unexpected exit >> of any backend process causes postmaster to restart the whole system anyway. > > Uh, yes, but don't we detect failures while modifying shared memory and > force a restart? Wouldn't the scope of failures be much larger? 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. -- Heikki Linnakangas Neon (https://neon.tech)
В списке pgsql-hackers по дате отправления: