Re: [GENERAL] Security implications of (plpgsql) functions
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [GENERAL] Security implications of (plpgsql) functions |
| Дата | |
| Msg-id | 24855.1035216162@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [GENERAL] Security implications of (plpgsql) functions (Bruce Momjian <pgman@candle.pha.pa.us>) |
| Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Crash reproduced here.
FWIW, I got a regular "out of memory" elog. But I can see that this
would depend on the relative sizes of data limit and stack limit on
a particular platform.
> I think we need to fix this by
> either setting a limit in the amount of function recursion, or allowing
> only the offending backend to crash without forcing all the other
> backends to crash.
Unless you can think of a way to distinguish stack overflow from other
kinds of SIGSEGV, I don't think we can avoid a system-wide restart.
Reducing stack overflow to a plain elog(ERROR) would be really nice,
but how?
A depth limit for PL-function recursion is perhaps feasible, but I can't
say that I care for it a whole lot ... anyone have better ideas?
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера