Re: PQexec() hangs on OOM
От | Amit Kapila |
---|---|
Тема | Re: PQexec() hangs on OOM |
Дата | |
Msg-id | CAA4eK1LCM0-oSYrQGTn+QAHkcW5ezWeMOLr=gV93RU-bmdrcOg@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 8:43 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Mon, Sep 7, 2015 at 10:41 PM, Michael Paquier wrote: > > In any case, attached are two patches: > > - 0001 adds the OOM/failure handling for the BIND and COPY start > > messages. This time the connection is not dropped. After a failure, > > successive commands work as well, this addresses the previous issue > > you reported. > > - 0002 is a cleanup bonus, getRowDescriptions and getAnotherTuple have > > some dead code that I think would be better removed, those are > > remnants from a copy/paste from the similar code of protocol 2. > > And I forgot... Attached is a simple program to test BIND messages. > Still the same test fails for me. postgres=# copy t1 from stdin; out of memory postgres=# copy t1 from stdin; --hangs here It hangs in second statement, basically I think you can't change the state to PGASYNC_BUSY on failure in case of copy in below code. + case PGASYNC_FATAL: + res = NULL; + /* + * Set the state back to BUSY, allowing parsing to proceed to + * consume messages coming from the server. + */ + conn->asyncStatus = PGASYNC_BUSY; + break; I think you need to keep the state as PGASYNC_COPY_*, so that the pending data can be discarded. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: