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