Re: Adding some error context for lock wait failures

Hi,

On 2025-08-29 15:46:33 -0400, Tom Lane wrote:
> Hearing no comments beyond that one, pushed.

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)
==374853== by 0xDA2076: ProcSleep (proc.c:1621)
==374853== by 0xD8CE85: WaitOnLock (lock.c:1979)
==374853== by 0xD8B9D8: LockAcquireExtended (lock.c:1221)
==374853== by 0xD8ACDA: LockAcquire (lock.c:814)
==374853== by 0xD93364: VirtualXactLock (lock.c:4844)
==374853== by 0xA4337E: WaitForOlderSnapshots (indexcmds.c:492)
==374853== by 0xA4A6DF: ReindexRelationConcurrently (indexcmds.c:4216)
==374853== by 0xA480B4: ReindexIndex (indexcmds.c:2956)
==374853== by 0xA47F12: ExecReindex (indexcmds.c:2885)
==374853== by 0xDBE60F: ProcessUtilitySlow (utility.c:1561)
==374853== by 0xDBCEA9: standard_ProcessUtility (utility.c:1060)
==374853== by 0xDBBB6A: ProcessUtility (utility.c:523)
==374853== by 0xDBA2D8: PortalRunUtility (pquery.c:1153)
==374853== by 0xDBA566: PortalRunMulti (pquery.c:1310)
==374853== by 0xDB99EB: PortalRun (pquery.c:788)
==374853==
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: definite
fun:palloc
fun:initStringInfoInternal
fun:initStringInfo
fun:waitonlock_error_callback
fun:errfinish
fun:ProcSleep
fun:WaitOnLock
fun:LockAcquireExtended
fun:LockAcquire
fun:VirtualXactLock
fun:WaitForOlderSnapshots
fun:ReindexRelationConcurrently
fun:ReindexIndex
fun:ExecReindex
fun:ProcessUtilitySlow
fun:standard_ProcessUtility
fun:ProcessUtility
fun:PortalRunUtility
fun:PortalRunMulti
fun:PortalRun
}

I suspect that the scope of the leak is somewhat bound, as ErrorContext will
be reset after errors. However it won't be reset if there aren't ever any
errors...

Greetings,

Andres Freund