From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Subject: | Re: Buffer locking is special (hints, checksums, AIO writes) |
Date: | 2025-10-09 20:35:44 |
Message-ID: | 3je3ahgf7rrmmurxo6hnlhg5d3ffwfrtjwjxd6jm5srlv5iebp@vxqk5qtgmowr |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I pushed a few commits from this patchset after Matthias' review
(thanks!). Unfortunately in 5e899859287 I missed that the valgrind annotations
would not be done anymore for the buffers returned by
StrategyGetBuffer(). Which turned skink red.
The attached 0001 patch centralizes the valgrind initialization in
TrackNewBufferPin(), which 5e899859287 had added. The nice side effect of that
is that there are fewer VALGRIND_MAKE_MEM_DEFINED() calls than before. The
naming isn't the perfect match, but it seems fine to me.
0002 is a new version of "Allow some buffer state modifications while holding
header lock", mainly with a fair bit of comment polishing around BufferDesc
and one small oversight fixed (didn't update a buffer_state variable in one
place).
Greetings,
Andres Freund
Attachment | Content-Type | Size |
---|---|---|
v5-0001-bufmgr-Fix-valgrind-checking-for-buffers-pinned-i.patch | text/x-diff | 3.1 KB |
v5-0002-bufmgr-Allow-some-buffer-state-modifications-whil.patch | text/x-diff | 31.3 KB |
v5-0003-bufmgr-Use-atomic-sub-for-unpinning-buffers.patch | text/x-diff | 2.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Burd | 2025-10-09 20:57:07 | Re: Expanding HOT updates for expression and partial indexes |
Previous Message | David Rowley | 2025-10-09 20:26:52 | Re: VACUUM (PARALLEL) option processing not using DefElem the way it was intended |