From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Marcin Owsiany <marcin(at)owsiany(dot)pl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] Security implications of (plpgsql) functions |
Date: | 2002-10-21 16:02:42 |
Message-ID: | 24855.1035216162@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeffrey Bohmer | 2002-10-21 16:08:52 | Re: Buffers and MacOS X |
Previous Message | Richard Huxton | 2002-10-21 16:02:18 | Re: Tutorial on postgreSQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeffrey Bohmer | 2002-10-21 16:08:52 | Re: Buffers and MacOS X |
Previous Message | D. Hageman | 2002-10-21 16:02:16 | Re: Postgresql and multithreading |