Re: Fix calloc check if oom (PQcancelCreate)
От | Jelte Fennema-Nio |
---|---|
Тема | Re: Fix calloc check if oom (PQcancelCreate) |
Дата | |
Msg-id | CAGECzQTr=mWMKKfX0ruTBrC=8QJQqHduwpN70uGdJvKfeuYCOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fix calloc check if oom (PQcancelCreate) (Ranier Vilela <ranier.vf@gmail.com>) |
Ответы |
Re: Fix calloc check if oom (PQcancelCreate)
|
Список | pgsql-hackers |
On Mon, 27 May 2024 at 16:06, Ranier Vilela <ranier.vf@gmail.com> wrote: > Em seg., 27 de mai. de 2024 às 10:23, Daniel Gustafsson <daniel@yesql.se> escreveu: >> > On 27 May 2024, at 14:25, Ranier Vilela <ranier.vf@gmail.com> wrote: >> > I think that commit 61461a3, left some oversight. >> > The function *PQcancelCreate* fails in check, >> > return of *calloc* function. >> > >> > Trivial fix is attached. >> >> Agreed, this looks like a copy/paste from the calloc calls a few lines up. > > Yeah. Agreed, this was indeed a copy paste mistake >> > But, IMO, I think that has more problems. >> > If any allocation fails, all allocations must be cleared. >> > Or is the current behavior acceptable? >> >> Since this is frontend library code I think we should free all the allocations >> in case of OOM. > > Agreed. > > With v1 patch, it is handled. I much prefer the original trivial patch to the v1. Even in case of OOM users are expected to call PQcancelFinish on a non-NULL result, which in turn calls freePGConn. And that function will free any partially initialized PGconn correctly. This is also how pqConnectOptions2 works.
В списке pgsql-hackers по дате отправления: