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
-
Clean up memory leakage that occurs in context callback functions.
- 89d57c1fb355 19 (unreleased) landed
-
Provide error context when an error is thrown within WaitOnLock().
- f727b63e8107 19 (unreleased) landed