| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Fix minor memory leak in connection string validation |
| Date: | 2024-01-13 03:18:55 |
| Message-ID: | 856130.1705115935@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> On Fri, Jan 12, 2024 at 03:06:26PM -0800, Jeff Davis wrote:
>> It makes me wonder if we should use the resowner mechanism to track
>> pointers to malloc'd memory. Then we could use a standard pattern for
>> these kinds of cases, and it would also catch more remote issues, like
>> if a pstrdup() fails in an error path (which can happen a few lines up
>> if the parse fails).
> That seems worth exploring.
I'm pretty dubious about adding overhead for that, mainly because
most of the direct callers of malloc in a backend are going to be
code that's not under our control. Modifying the callers that we
do control is not going to give a full solution, and could well be
outright misleading.
> Another option could be to surround this with PG_TRY/PG_FINALLY, but your
> patch seems sufficient, too.
Yeah, seems fine for now. If that function grows any more complexity
then we could think about using PG_TRY.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2024-01-13 04:35:52 | Re: Synchronizing slots from primary to standby |
| Previous Message | Nathan Bossart | 2024-01-13 02:37:05 | Re: Fix minor memory leak in connection string validation |