Re: Fix calloc check if oom (PQcancelCreate)
Jelte Fennema-Nio <postgres@jeltef.nl>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Ranier Vilela <ranier.vf@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-05-27T15:40:23Z
Lists: 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.
Commits
-
Fix check for memory allocation
- 4013a5ada252 17.0 landed
-
libpq: Add encrypted and non-blocking query cancellation routines
- 61461a300c1c 17.0 cited