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
|
Список | 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 по дате отправления: