Re: PQexec() hangs on OOM

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
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

In response to

Responses

Browse pgsql-bugs by date

  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