agora inbox for pgsql-committers@postgresql.org  
help / color / mirror / Atom feed
pgsql: bufmgr: Fix order of operations in UnlockBufHdrExt
2+ messages / 1 participants
[nested] [flat]

* pgsql: bufmgr: Fix order of operations in UnlockBufHdrExt
@ 2026-07-10 17:27  Andres Freund <andres@anarazel.de>
  0 siblings, 0 replies; 2+ messages in thread

From: Andres Freund @ 2026-07-10 17:27 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

bufmgr: Fix order of operations in UnlockBufHdrExt

In c75ebc657ffc I (Andres) introduced UnlockBufHdrExt() which can set and
clear bits in the buffer state using CAS. Unfortunately I added bits before
subtracting them, which means that a bit that was both removed and set would
remain unset.  Fix the order of operations.

The only known case where that is a problem is that BM_IO_ERROR would not
actually remain set.

It's unfortunately not trivial to add a decent, race-free, test to verify that
BM_IO_ERROR remains set. That's therefore left for the 20 cycle.

Reported-by: Yura Sokolov <y.sokolov@postgrespro.ru>
Discussion: https://postgr.es/m/ab0dcc9e-aba0-44e3-ac23-8d74c48888e6@postgrespro.ru
Backpatch-through: 19, where c75ebc657ffc went in

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/c787c952bc882626c66ec64b1d35a664902bfa8b

Modified Files
--------------
src/include/storage/buf_internals.h | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)



^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* pgsql: bufmgr: Fix order of operations in UnlockBufHdrExt
@ 2026-07-10 17:27  Andres Freund <andres@anarazel.de>
  0 siblings, 0 replies; 2+ messages in thread

From: Andres Freund @ 2026-07-10 17:27 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

bufmgr: Fix order of operations in UnlockBufHdrExt

In c75ebc657ffc I (Andres) introduced UnlockBufHdrExt() which can set and
clear bits in the buffer state using CAS. Unfortunately I added bits before
subtracting them, which means that a bit that was both removed and set would
remain unset.  Fix the order of operations.

The only known case where that is a problem is that BM_IO_ERROR would not
actually remain set.

It's unfortunately not trivial to add a decent, race-free, test to verify that
BM_IO_ERROR remains set. That's therefore left for the 20 cycle.

Reported-by: Yura Sokolov <y.sokolov@postgrespro.ru>
Discussion: https://postgr.es/m/ab0dcc9e-aba0-44e3-ac23-8d74c48888e6@postgrespro.ru
Backpatch-through: 19, where c75ebc657ffc went in

Branch
------
REL_19_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/a1b74b7279c24638c44f9d3d1af2da30cfb7068d

Modified Files
--------------
src/include/storage/buf_internals.h | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)



^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2026-07-10 17:27 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-07-10 17:27 pgsql: bufmgr: Fix order of operations in UnlockBufHdrExt Andres Freund <andres@anarazel.de>
2026-07-10 17:27 pgsql: bufmgr: Fix order of operations in UnlockBufHdrExt Andres Freund <andres@anarazel.de>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox