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: Matheus Alcantara <matheusssilv97@gmail.com>
Cc: Etsuro Fujita <etsuro.fujita@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-05-28T20:56:32Z
Lists: pgsql-hackers

Attachments

I wrote:
> Having said that, the idea that this sequence is OOM-safe is pretty
> silly anyway, considering that createNewConnection does a pstrdup,
> and creates a new hashtable entry which might require enlarging the
> hashtable, and for that matter might even create the hashtable.
> So maybe rather than continuing to adhere to a half-baked coding
> rule, we need to think of some other way to do that.

Here's an attempt at fixing this properly.  I'm posting it as a
standalone patch because I now think this part might be worth
back-patching.  The odds of an OOM at just the wrong time aren't
high, but losing track of an open connection seems pretty bad.

			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.