Re: Issue with the PRNG used by Postgres

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Issue with the PRNG used by Postgres
Дата
Msg-id CA+TgmoZdy5nChPK3k0FvJ0_Vai+6OxE5om3GpOnU=jFE22j02g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Issue with the PRNG used by Postgres  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Issue with the PRNG used by Postgres  (Andres Freund <andres@anarazel.de>)
Re: Issue with the PRNG used by Postgres  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Apr 10, 2024 at 9:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Maybe we should rip out the whole mechanism and hard-wire
> spins_per_delay at 1000 or so.

Or, rip out the whole, whole mechanism and just don't PANIC.

I'm not 100% sure that's better, but I think it's worth considering.
The thing is, if you're panicking regularly, that's almost as bad as
being down, because you're going to lose all of your connections and
have to run recovery before they can be reestablished. And if you're
panicking once in a blue moon, the PANIC actually prevents you from
easily getting a stack trace that might help you figure out what's
happening. And of course if it's not really a stuck spinlock but just
a very slow system, which I think is an extremely high percentage of
real-world cases, then it's completely worthless at best.

To believe that the PANIC is the right idea, we have to suppose that
we have stuck-spinlock bugs that people actually hit, but that those
people don't hit them often enough to care, as long as the system
resets when the spinlock gets stuck, instead of hanging. I can't
completely rule out the existence of either such bugs or such people,
but I'm not aware of having encountered them.

--
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: allow changing autovacuum_max_workers without restarting
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Issue with the PRNG used by Postgres