From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Zhang Mingli <zmlpostgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com> |
Subject: | Re: Adding some error context for lock wait failures |
Date: | 2025-10-09 16:50:53 |
Message-ID: | 3017219.1760028653@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
v1-clear-error-context-after-non-error.patch | text/x-diff | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2025-10-09 16:55:12 | Re: Adding some error context for lock wait failures |
Previous Message | Álvaro Herrera | 2025-10-09 16:36:58 | Re: memory leak in dbase_redo() |