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 |
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 |