Re: PQexec() hangs on OOM
От | Michael Paquier |
---|---|
Тема | Re: PQexec() hangs on OOM |
Дата | |
Msg-id | CAB7nPqQPaDb+=GCkdZb1L-VbpJTiigPx9_UNTA1a4H2MLGi9XA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PQexec() hangs on OOM (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PQexec() hangs on OOM
|
Список | pgsql-bugs |
On Mon, Apr 6, 2015 at 10:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.com> writes: >> Second idea: return a status with parseInput as it is not part of the APIs >> of libpq. > > Yeah; most subroutines in libpq have a zero-or-EOF return convention, > we can make parseInput do likewise. I'm not sure if that'd need to > propagate further down though ... So, I have been looking at that in more details, and finished with the patch attached that makes the problem go away for me with a nice "out of memory" error. I have extended parseInput() to have it return a status code to decide if parsing should be stopped or should continue. Note that I have tried to be careful to make a clear distinction between cases where routines return EOF because of not enough data parsed and actual OOMs. I have noticed as well that getCopyStart() in fe-protocol3.c needs to be made a little bit smarter to make the difference between an OOM and the not-enough-data type of problem. This problem has a low probability to happen in the field, and no people complained about that as well, so I think that patching only HEAD is adapted. Regards, -- Michael
Вложения
В списке pgsql-bugs по дате отправления: