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 |
Date: | 2015-04-07 06:18:31 |
Message-ID: | CAB7nPqQPaDb+=GCkdZb1L-VbpJTiigPx9_UNTA1a4H2MLGi9XA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
Regards,
--
Michael
Attachment | Content-Type | Size |
---|---|---|
0001-Improve-OOM-detection-of-parseInput-in-libpq.patch | text/x-patch | 19.2 KB |
From | Date | Subject | |
---|---|---|---|
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 |