From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Jeff Davis <pgsql@j-davis.com>, pgsql-hackers@postgresql.org
Subject: Re: Fix minor memory leak in connection string validation
In-reply-to: <20240113023705.GA4039878@nathanxps13>
References: <066a65233d3cb4ea27a9e0778d2f1d0dc764b222.camel@j-davis.com> <20240113023705.GA4039878@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Fri, 12 Jan 2024 20:37:05 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <856129.1705115935.1@sss.pgh.pa.us>
Date: Fri, 12 Jan 2024 22:18:55 -0500
Message-ID: <856130.1705115935@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/856130.1705115935%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.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