|From:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||hlinnaka(at)iki(dot)fi, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>|
|Subject:||Re: PQexec() hangs on OOM|
|Views:||Raw Message | Whole Thread | Download mbox|
On Mon, Apr 6, 2015 at 10:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)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.
|Next Message||Kingter Wang||2015-04-07 07:22:02||pg_rewind TAP tests won't run in 'remote' mode|
|Previous Message||antoine||2015-04-07 04:07:56||BUG #12991: RESTART IDENTITY is not doing anything|