Re: Let's make PostgreSQL multi-threaded

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Let's make PostgreSQL multi-threaded
Дата
Msg-id ZH4jkbtflmhgyyue@momjian.us
обсуждение исходный текст
Ответ на Re: Let's make PostgreSQL multi-threaded  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Let's make PostgreSQL multi-threaded  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
On Mon, Jun  5, 2023 at 08:29:16PM +0300, Heikki Linnakangas wrote:
> On 05/06/2023 13:10, Bruce Momjian wrote:
> > nOn Mon, Jun  5, 2023 at 05:51:57PM +0300, Heikki Linnakangas wrote:
> > > # Restart on crash
> > > 
> > > If a backend process crashes, postmaster terminates all other backends and
> > > restarts the system. That's hard (impossible?) to do safely if everything
> > > runs in one process. We can continue have a separate postmaster process that
> > > just monitors the main process and restarts it on crash.
> > 
> > It would be good to know what new class of errors would cause server
> > restarts, e.g., memory allocation failures?
> 
> You mean "out of memory"? No, that would be horrible.
> 
> 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?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Order changes in PG16 since ICU introduction
Следующее
От: Alexander Pyhalov
Дата:
Сообщение: Re: Partial aggregates pushdown