Fix possible resource leaks (src/backend/replication/logical/conflict.c)
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t50228psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 11:38 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t50228_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t50228_1 && git checkout t50228_1Patchset v1 (message #1) is on t50228_1
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
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