8000 Fix memory leakage in postgres_fdw's DirectModify code path. · postgres/postgres@271cb7e · GitHub
[go: up one dir, main page]

Skip to content

Commit 271cb7e

Browse files
committed
Fix memory leakage in postgres_fdw's DirectModify code path.
postgres_fdw tries to use PG_TRY blocks to ensure that it will eventually free the PGresult created by the remote modify command. However, it's fundamentally impossible for this scheme to work reliably when there's RETURNING data, because the query could fail in between invocations of postgres_fdw's DirectModify methods. There is at least one instance of exactly this situation in the regression tests, and the ensuing session-lifespan leak is visible under Valgrind. We can improve matters by using a memory context reset callback attached to the ExecutorState context. That ensures that the PGresult will be freed when the ExecutorState context is torn down, even if control never reaches postgresEndDirectModify. I have little faith that there aren't other potential PGresult leakages in the backend modules that use libpq. So I think it'd be a good idea to apply this concept universally by creating infrastructure that attaches a reset callback to every PGresult generated in the backend. However, that seems too invasive for v18 at this point, let alone the back branches. So for the moment, apply this narrow fix that just makes DirectModify safe. I have a patch in the queue for the more general idea, but it will have to wait for v19. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com> Discussion: https://postgr.es/m/2976982.1748049023@sss.pgh.pa.us Backpatch-through: 13
1 parent c81cdff commit 271cb7e

File tree

1 file changed

+33
-27
lines changed

1 file changed

+33
-27
lines changed

contrib/postgres_fdw/postgres_fdw.c

Lines changed: 33 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -222,6 +222,7 @@ typedef struct PgFdwDirectModifyState
222222
PGresult *result; /* result for query */
223223
int num_tuples; /* # of result tuples */
224224
int next_tuple; /* index of next one to return */
225+
MemoryContextCallback result_cb; /* ensures result will get freed */
225226
Relation resultRel; /* relcache entry for the target relation */
226227
AttrNumber *attnoMap; /* array of attnums of input user columns */
227228
AttrNumber ctidAttno; /* attnum of input ctid column */
@@ -2358,6 +2359,17 @@ postgresBeginDirectModify(ForeignScanState *node, int eflags)
23582359
dmstate = (PgFdwDirectModifyState *) palloc0(sizeof(PgFdwDirectModifyState));
23592360
node->fdw_state = (void *) dmstate;
23602361

2362+
/*
2363+
* We use a memory context callback to ensure that the dmstate's PGresult
2364+
* (if any) will be released, even if the query fails somewhere that's
2365+
* outside our control. The callback is always armed for the duration of
2366+
* the query; this relies on PQclear(NULL) being a no-op.
2367+
*/
2368+
dmstate->result_cb.func = (MemoryContextCallbackFunction) PQclear;
2369+
dmstate->result_cb.arg = NULL;
2370+
MemoryContextRegisterResetCallback(CurrentMemoryContext,
2371+
&dmstate->result_cb);
2372+
23612373
/*
23622374
* Identify which user to do the remote access as. This should match what
23632375
* ExecCheckRTEPerms() does.
@@ -2507,7 +2519,12 @@ postgresEndDirectModify(ForeignScanState *node)
25072519

25082520
/* Release PGresult */
25092521
if (dmstate->result)
2522+
{
25102523
PQclear(dmstate->result);
2524+
dmstate->result = NULL;
2525+
/* ... and don't forget to disable the callback */
2526+
dmstate->result_cb.arg = NULL;
2527+
}
25112528

25122529
/* Release remote connection */
25132530
ReleaseConnection(dmstate->conn);
@@ -4085,13 +4102,17 @@ execute_dml_stmt(ForeignScanState *node)
40854102
/*
40864103
* Get the result, and check for success.
40874104
*
4088-
* We don't use a PG_TRY block here, so be careful not to throw error
4089-
* without releasing the PGresult.
4105+
* We use a memory context callback to ensure that the PGresult will be
4106+
* released, even if the query fails somewhere that's outside our control.
4107+
* The callback is already registered, just need to fill in its arg.
40904108
*/
4109+
Assert(dmstate->result == NULL);
40914110
dmstate->result = pgfdw_get_result(dmstate->conn, dmstate->query);
4111+
dmstate->result_cb.arg = dmstate->result;
4112+
40924113
if (PQresultStatus(dmstate->result) !=
40934114
(dmstate->has_returning ? PGRES_TUPLES_OK : PGRES_COMMAND_OK))
4094-
pgfdw_report_error(ERROR, dmstate->result, dmstate->conn, true,
4115+
pgfdw_report_error(ERROR, dmstate->result, dmstate->conn, false,
40954116
dmstate->query);
40964117

40974118
/* Get the number of rows affected. */
@@ -4135,31 +4156,16 @@ get_returning_data(ForeignScanState *node)
41354156
}
41364157
else
41374158
{
4138-
/*
4139-
* On error, be sure to release the PGresult on the way out. Callers
4140-
* do not have PG_TRY blocks to ensure this happens.
4141-
*/
4142-
PG_TRY();
4143-
{
4144-
HeapTuple newtup;
4145-
4146-
newtup = make_tuple_from_result_row(dmstate->result,
4147-
dmstate->next_tuple,
4148-
dmstate->rel,
4149-
dmstate->attinmeta,
4150-
dmstate->retrieved_attrs,
4151-
node,
4152-
dmstate->temp_cxt);
4153-
ExecStoreHeapTuple(newtup, slot, false);
4154-
}
4155-
PG_CATCH();
4156-
{
4157-
if (dmstate->result)
4158-
PQclear(dmstate->result);
4159-
PG_RE_THROW();
4160-
}
4161-
PG_END_TRY();
4159+
HeapTuple newtup;
41624160

4161+
newtup = make_tuple_from_result_row(dmstate->result,
4162+
dmstate->next_tuple,
4163+
dmstate->rel,
4164+
dmstate->attinmeta,
4165+
dmstate->retrieved_attrs,
4166+
node,
4167+
dmstate->temp_cxt);
4168+
ExecStoreHeapTuple(newtup, slot, false);
41634169
/* Get the updated/deleted tuple. */
41644170
if (dmstate->rel)
41654171
resultSlot = slot;

0 commit comments

Comments
 (0)
0