Re: PQexec() hangs on OOM
От | Michael Paquier |
---|---|
Тема | Re: PQexec() hangs on OOM |
Дата | |
Msg-id | CAB7nPqRROGvaiL0hzwum0+7EQjQij1u9am4pFnG54GzVdegs2g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PQexec() hangs on OOM (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: PQexec() hangs on OOM
|
Список | pgsql-bugs |
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? > That left me with the attached patch. It doesn't handle the > getParamDescription() case, nor the getCopyStart() case, but it's a start. > We don't necessarily need to fix everything in one go. Does this look > correct to you, as far as it goes? I have been carefully through the routines modified, doing some tests at the same time and I haven't spotted an issue. -- Michael
В списке pgsql-bugs по дате отправления: