Fix possible resource leaks (src/backend/replication/logical/conflict.c)
Hi.
Per Coverity.
The commit 9758174 <http://9758174e2e5cd278cf37e0980da76b51890e0011>,
included the source src/backend/replication/logical/conflict.c.
The function *errdetail_apply_conflict* reports potential conflicts.
But do not care about possible resource leaks.
However, the leaked size can be considerable, since it can have logs with
the LOG level.
The function *ReportSlotInvalidation* has similar utility, but on the
contrary, be careful not to leak.
IMO, these potential leaks need to be fixed.
Patch attached.
best regards,
Ranier Vilela
Attachments:
0001-fix-possible-resources-leaks-conflict.patchapplication/octet-stream; name=0001-fix-possible-resources-leaks-conflict.patchDownload
diff --git a/src/backend/replication/logical/conflict.c b/src/backend/replication/logical/conflict.c
index 5d9ff626bd..dabe278b72 100644
--- a/src/backend/replication/logical/conflict.c
+++ b/src/backend/replication/logical/conflict.c
@@ -201,6 +201,7 @@ errdetail_apply_conflict(EState *estate, ResultRelInfo *relinfo,
StringInfoData err_detail;
char *val_desc;
char *origin_name;
+ int errd;
initStringInfo(&err_detail);
@@ -289,9 +290,15 @@ errdetail_apply_conflict(EState *estate, ResultRelInfo *relinfo,
* replica identity columns after the message.
*/
if (val_desc)
+ {
appendStringInfo(&err_detail, "\n%s", val_desc);
+ pfree(val_desc);
+ }
+
+ errd = errdetail_internal("%s", err_detail.data);
+ pfree(err_detail.data);
- return errdetail_internal("%s", err_detail.data);
+ return errd;
}
/*
Ranier Vilela <ranier.vf@gmail.com> writes:
Per Coverity.
Coverity is never to be trusted about "leaks" in the backend,
because it has no idea about short- versus long-lived memory
contexts.
The function *errdetail_apply_conflict* reports potential conflicts.
But do not care about possible resource leaks.
However, the leaked size can be considerable, since it can have logs with
the LOG level.
The function *ReportSlotInvalidation* has similar utility, but on the
contrary, be careful not to leak.
IMO, these potential leaks need to be fixed.
This is nonsense. If there is a problem here, then we also have
leaks to worry about in the immediate caller ReportApplyConflict,
not to mention its callers. The correct solution is to be sure that
the whole thing happens in a short-lived context, which I believe
is true --- looks like it should be running in ApplyMessageContext,
which will be reset after each replication message.
(I'm inclined to suspect that that pfree in ReportSlotInvalidation
is equally useless, but I didn't track down its call sites.)
regards, tom lane