Re: Adding some error context for lock wait failures - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Adding some error context for lock wait failures
Date
Msg-id 2957957.1760025882@sss.pgh.pa.us
Whole thread Raw
In response to Re: Adding some error context for lock wait failures  (Andres Freund <andres@anarazel.de>)
Responses Re: Adding some error context for lock wait failures
List 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Thoughts on a "global" client configuration?
Next
From: Melanie Plageman
Date:
Subject: Re: Incorrect logic in XLogNeedsFlush()