Re: Adding some error context for lock wait failures

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

In response to

Responses

Browse pgsql-hackers by date

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