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  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: James Coleman
Дата:
Сообщение: Re: RFC: Logging plan of the running query
Следующее
От: reid.thompson@crunchydata.com
Дата:
Сообщение: Re: Add the ability to limit the amount of memory that can be allocated to backends.