Re: Adding some error context for lock wait failures

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

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-09T16:04:42Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2025-10-09 11:22:39 -0400, Tom Lane wrote:
>> 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...

Yeah.  I see that errfinish does FreeErrorDataContents in the
non-ERROR code path, but of course that does nothing for random
leakages during error processing.  I'm tempted to have it do
MemoryContextReset(ErrorContext) if we are at stack depth zero.
That'd be unsafe during nested error processing, but there
should not be anything of interest leftover once we're out
of the nest.

			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().