Re: Phantom Command ID

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Phantom Command ID
Дата
Msg-id 18367.1158783767@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Phantom Command ID  ("Jim C. Nasby" <jim@nasby.net>)
Ответы Re: Phantom Command ID  ("Jim C. Nasby" <jim@nasby.net>)
Список pgsql-hackers
"Jim C. Nasby" <jim@nasby.net> writes:
> What would the failure mode be? Would we just keep going until the box
> ran out of memory? I think it'd be better to have some kind of hard
> limit so that a single backend can't grind a production server into a
> swap-storm. (Arguably, not having a limit is exposing a DoS
> vulnerability).

[ shrug... ]  If we tried to guarantee such a thing we'd be putting
arbitrary limits into hundreds if not thousands of different bits of the
backend.  I think the correct answer for an admin who is worried about
such a thing is to make sure that the process ulimit is a sufficiently
small fraction of the machine's available RAM.  Only if we can't
gracefully handle running up against ulimit is it our problem (hence,
we have a stack-size overflow check, but not any such thing for data size).
        regards, tom lane


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

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: [PATCHES] Incrementally Updated Backup
Следующее
От: David Fetter
Дата:
Сообщение: Re: Units in postgresql.conf.sample