Hi, On 2025-10-09 11:22:39 -0400, Tom Lane wrote: > Andres Freund <[email protected]> writes: > > valgrind complains that there's a memory leak here: > > > ==374853== 1,024 bytes in 1 blocks are definitely lost in loss record 1,257 > > of 1,459 > > ==374853== at 0xFD902A: palloc (mcxt.c:1389) > > ==374853== by 0x101A3D6: initStringInfoInternal (stringinfo.c:45) > > ==374853== by 0x101A46B: initStringInfo (stringinfo.c:99) > > ==374853== by 0xD8CF32: waitonlock_error_callback (lock.c:2027) > > ==374853== by 0xF916E2: errfinish (elog.c:510) > > Hmm, that is interesting -- I'd expect error cleanup to deal with > that. Did you happen to notice the exact repro case? It's surely > easy enough to add a pfree, but I don't believe that other errcontext > callbacks are any more careful than this one.
I think the difference to most other cases is that this is just an informational message, so there simply isn't any error cleanup. It's possible we should change that, as you say it's not hard to imagine other error contexts called in < ERROR cases also leaking... As for a repro, it seems the basic case of A: CREATE TABLE foo(); A: BEGIN; LOCK TABLE foo; B: BEGIN; LOCK TABLE foo; A: SELECT pg_sleep(2); A: COMMIT; B: \c triggers it. Of course the backtrace is slightly different in that case compared to the case that I reported upthread. Greetings, Andres Freund
