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
