Re: PQexec() hangs on OOM
От | Amit Kapila |
---|---|
Тема | Re: PQexec() hangs on OOM |
Дата | |
Msg-id | CAA4eK1KVnY1n1uM7oAPs17OnUDtJQozb4E2r_L0PL7v_v62qdA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PQexec() hangs on OOM (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: PQexec() hangs on OOM
|
Список | pgsql-bugs |
On Thu, Jul 9, 2015 at 6:34 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > > On Wed, Jul 8, 2015 at 1:01 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > > On 07/07/2015 09:32 AM, Michael Paquier wrote: > > > > > > 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. > > So, here are two patches aimed at fixing the hangling issues with > getStartCopy and getParamDescriptions. After trying a couple of > approaches, I found out that the most elegant way to prevent the > infinite loop in parseInput is to introduce a new PGASYNC flag to > control the error and let the caller know what happened. One thing that looks slightly non-elegant about this approach is that new async status (PGASYNC_FATAL) is used to deal with errors only in few paths in function pqParseInput3() and not-other paths which should be okay if there is no other better way. I have not spent enough time on it to suggest any better alternative, but would like to hear what other approaches you have considered? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: