Re: PQexec() hangs on OOM
От | Michael Paquier |
---|---|
Тема | Re: PQexec() hangs on OOM |
Дата | |
Msg-id | CAB7nPqT4_LD+LE-t-JAL-rhr8QrYO4AgY-j2jnLcSv-n3GYpOw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PQexec() hangs on OOM (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: PQexec() hangs on OOM
|
Список | 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 по дате отправления: