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

From Andres Freund
Subject Re: Adding some error context for lock wait failures
Date
Msg-id zldbjeb7exalzmfyro3g2lgo2n524wbraeiwwrmyi7q2yz6je4@ewgj63pyscml
Whole thread Raw
In response to Re: Adding some error context for lock wait failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Adding some error context for lock wait failures
List pgsql-hackers
Hi,

On 2025-10-09 12:50:53 -0400, Tom Lane wrote:
> 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.

Sorry, was working on a fix when life rudely intervened.  Here's a quick
temporary fix:

diff --git i/src/backend/storage/buffer/bufmgr.c w/src/backend/storage/buffer/bufmgr.c
index d69e08ae61e..51c21e2ee06 100644
--- i/src/backend/storage/buffer/bufmgr.c
+++ w/src/backend/storage/buffer/bufmgr.c
@@ -3325,6 +3325,9 @@ TrackNewBufferPin(Buffer buf)
     ref->refcount++;
 
     ResourceOwnerRememberBuffer(CurrentResourceOwner, buf);
+
+    VALGRIND_MAKE_MEM_DEFINED(BufHdrGetBlock(GetBufferDescriptor(buf - 1)), BLCKSZ);
+
 }
 
 #define ST_SORT sort_checkpoint_bufferids

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Adding some error context for lock wait failures
Next
From: Masahiko Sawada
Date:
Subject: Re: Invalid pointer access in logical decoding after error