Horton

Re: Adding some error context for lock wait failures

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, Zhang Mingli <zmlpostgres@gmail.com>, pgsql-hackers@lists.postgresql.org, Steve Baldwin <steve.baldwin@gmail.com>
Date: 2025-10-09T15:22:39Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> 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.

			regards, tom lane

Commits

  1. Clean up memory leakage that occurs in context callback functions.

  2. Provide error context when an error is thrown within WaitOnLock().