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
- v1-clear-error-context-after-non-error.patch (text/x-diff) patch v1
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
-
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