Re: PQexec() hangs on OOM
От | Amit Kapila |
---|---|
Тема | Re: PQexec() hangs on OOM |
Дата | |
Msg-id | CAA4eK1LHAvJUZTVdV1nuGPXKibqNwV-HPaD8W-axLKXrVdr+Ew@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PQexec() hangs on OOM (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: PQexec() hangs on OOM
|
Список | pgsql-bugs |
On Mon, Sep 7, 2015 at 1:40 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > > On Sat, Sep 5, 2015 at 9:45 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > So, I think that the right approach would be to leave immediately > pqParseInput3 should an error happen, switching asyncStatus to leave > the loop in PQgetResult. Sure, if you think that works, then do it that way. > This seems as well to work correctly with > PGRES_COPY_BOTH (I emulated failures with pg_basebackup and errors > were caught up correctly. This brings back of course the introduction > of a new flag PGASYNC_FATAL I think we should try not to introduce this new flag, as that is not merely a flag, but rather a state in query-execution state machine. Now if we introduce a new error state into that state-machine, then it doesn't seem like a good idea to do that only for some of the paths and doing it for all other paths is a call for somewhat larger verification cycle (to see if it works in all paths as previously). With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: