Re: Fixing memory leaks in postgres_fdw

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fixing memory leaks in postgres_fdw
Date: 2025-05-25 23:59:00
Message-ID: 519144.1748217540@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Here is an attempt at making a bulletproof fix by having all backend
> users of libpq go through a wrapper layer that provides the memory
> context callback. Perhaps this is more code churn than we want to
> accept; I'm not sure. I thought about avoiding most of the niggling
> code changes by adding
> #define PGresult BEPGresult
> #define PQclear BEPQclear
> #define PQresultStatus BEPQresultStatus
> and so forth at the bottom of the new header file, but I'm afraid
> that would create a lot of confusion.

I tried that, and it leads to such a less-messy patch that I think
we should probably do it this way, confusion or no. One argument
that can be made in favor is that we don't really want random
notational differences between frontend and backend code that's
doing the same thing.

Also, I'd been struggling with the assumption that we should
palloc the wrapper object before calling PQgetResult; there
doesn't seem to be any nice way to make that transparent to
callers. I realized that we can make it simple as long as
we're willing to assume that allocating with MCXT_ALLOC_NO_OOM
can't throw an error. But we assume that in other usages too.

Hence, v3 attached. The 0002 patch is still the same as before.

regards, tom lane

Attachment Content-Type Size
v3-0001-Fix-memory-leakage-in-postgres_fdw-s-DirectModify.patch text/x-diff 21.3 KB
v3-0002-Silence-leakage-complaint-about-postgres_fdw-s-In.patch text/x-diff 3.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-05-26 00:05:49 Re: Non-reproducible AIO failure
Previous Message Thomas Munro 2025-05-25 23:44:48 Re: Non-reproducible AIO failure