Horton

Re: Fixing memory leaks in postgres_fdw

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Matheus Alcantara <matheusssilv97@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-07-25T20:49:52Z
Lists: pgsql-hackers 
Etsuro Fujita <etsuro.fujita@gmail.com> writes:
> On Fri, May 30, 2025 at 2:02 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Finally, here's a minimalistic version of the original v1-0001
>> patch that I think we could safely apply to fix the DirectModify
>> problem in the back branches.  I rejiggered it to not depend on
>> inventing MemoryContextUnregisterResetCallback, so that there's
>> not hazards of minor-version skew between postgres_fdw and the
>> main backend.

> Seems reasonable.

Pushed the larger patchset now.  I had to do a little more work
to get it to play with 112faf137, but it wasn't hard.

			regards, tom lane

Commits

  1. Silence leakage complaint about postgres_fdw's InitPgFdwOptions.

  2. Run pgindent on the changes of the previous patch.

  3. Reap the benefits of not having to avoid leaking PGresults.

  4. Create infrastructure to reliably prevent leakage of PGresults.

  5. Fix memory leakage in postgres_fdw's DirectModify code path.

  6. Avoid resource leaks when a dblink connection fails.