Re: PQexec() hangs on OOM - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: PQexec() hangs on OOM
Date
Msg-id CAB7nPqT4_LD+LE-t-JAL-rhr8QrYO4AgY-j2jnLcSv-n3GYpOw@mail.gmail.com
Whole thread Raw
In response to Re: PQexec() hangs on OOM  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: PQexec() hangs on OOM  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-bugs
On Tue, Jul 7, 2015 at 3:31 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Jul 7, 2015 at 2:13 AM, Heikki Linnakangas wrote:
>> The getParamDescriptions() changes were slightly broken. It didn't read the
>> whole input message with pqGetInt() etc., so pqParseInput3() threw the
>> "message contents do not agree with length in message type" error. I started
>> fixing that, by changing the error handling in that function to be more like
>> that in getRowDescriptions(), but then I realized that all the EOF return
>> cases in the pqParseInput3() subroutines are actually dead code.
>> pqParseInput3() always reads the whole message, before passing it on to the
>> right subroutine. That was documented for getRowDescriptions() and
>> getAnotherTuple(), but the rest of the functions were more like the protocol
>> version 2 code, prepared to deal with incomplete messages. I think it would
>> be good to refactor that, removing the EOF return cases altogether. So I
>> left out that change for now as well.
>
> Yes, (the latter case is not actually used currently). Well, I don't
> mind writing the additional patch to update . On top of that The
> refactoring should be a master-only change, perhaps?

I pushed the send button too early.
I don't mind writing the additional patch for the other routines,
patch that should be backpatched, and the refactoring patch
(master-only?).
--
Michael

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: PQexec() hangs on OOM
Next
From: Michael Paquier
Date:
Subject: Re: contribcheck and modulescheck of MSVC's vcregress.pl cannot work independently