Re: [GENERAL] Security implications of (plpgsql) functions

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [GENERAL] Security implications of (plpgsql) functions
Следующее
От: Joe Conway
Дата:
Сообщение: Re: [GENERAL] Security implications of (plpgsql) functions