From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix calloc check if oom (PQcancelCreate) |
Date: | 2024-05-27 15:40:23 |
Message-ID: | CAGECzQTr=mWMKKfX0ruTBrC=8QJQqHduwpN70uGdJvKfeuYCOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 27 May 2024 at 16:06, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> Em seg., 27 de mai. de 2024 às 10:23, Daniel Gustafsson <daniel(at)yesql(dot)se> escreveu:
>> > On 27 May 2024, at 14:25, Ranier Vilela <ranier(dot)vf(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2024-05-27 16:16:15 | Re: Fix calloc check if oom (PQcancelCreate) |
Previous Message | Alexander Lakhin | 2024-05-27 15:00:00 | Test 031_recovery_conflict fails when a conflict counted twice |