Re: PQexec() hangs on OOM

On 07/07/2015 09:32 AM, Michael Paquier wrote:
> On Tue, Jul 7, 2015 at 3:31 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)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?).

Ok, committed and backpatched the latest patch I posted. Yeah, we'll
need additional patches for the refactoring and the remaining issues.
I'm not sure if it's worth trying to backpatch them; let's see how big
the patch is.

- Heikki