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:50:53Z
Lists: pgsql-hackers

Attachments

I wrote:
> 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.

Concretely, like the attached.  This passes check-world, but
I can't test it under valgrind because I'm hitting the same
CREATE DATABASE failure skink is reporting.

I wonder if we should back-patch this.  In principle, a backend
that emits a long series of non-error log messages or client
notice messages could accumulate indefinitely much leakage in
ErrorContext.  The lack of field reports suggests that maybe
there weren't any such leaks up to now, but that seems unduly
optimistic.

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