Re: Avoid possible dereference null pointer (src/backend/catalog/pg_depend.c)

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid possible dereference null pointer (src/backend/catalog/pg_depend.c)
Date: 2024-05-24 12:05:35
Message-ID: CAEudQAoPQd6WJ13qfNu49JthpRrvUV__uUmGg+4w20udd-Wa6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em sex., 24 de mai. de 2024 às 08:48, Ashutosh Bapat <
ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> escreveu:

>
>
> On Fri, May 24, 2024 at 12:16 PM Michael Paquier <michael(at)paquier(dot)xyz>
> wrote:
>
>> On Fri, May 24, 2024 at 11:58:51AM +0530, Ashutosh Bapat wrote:
>> > If we are looking for avoiding a segfault and get a message which helps
>> > debugging, using get_attname and get_attnum might be better options.
>> > get_attname throws an error. get_attnum doesn't throw an error and
>> returns
>> > InvalidAttnum which won't return any valid identity sequence, and thus
>> > return a NIL sequence list which is handled in that function already.
>> Using
>> > these two functions will avoid the clutter as well as segfault. If
>> that's
>> > acceptable, I will provide a patch.
>>
>> Yeah, you could do that with these two routines as well. The result
>> would be the same in terms of runtime validity checks.
>>
>
> PFA patch using those two routines.
>
The function *get_attname* palloc the result name (pstrdup).
Isn't it necessary to free the memory here (pfree)?

best regards,
Ranier Vilela

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Srinath Reddy Sadipiralla 2024-05-24 12:17:00 Question: Why Are File Descriptors Not Closed and Accounted for PostgreSQL Backends?
Previous Message Ashutosh Bapat 2024-05-24 11:48:32 Re: Avoid possible dereference null pointer (src/backend/catalog/pg_depend.c)