Re: [PATCH] bufmgr: tighten LWLock:BufferMapping on InvalidateBuffer

From: Yuhang Qiu <iamqyh(at)gmail(dot)com>
To: Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] bufmgr: tighten LWLock:BufferMapping on InvalidateBuffer
Date: 2026-09-11 09:56:15
Message-ID: 318A4D41-5CB8-4B2B-84AC-BDC8B52E0F4D@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Alexandre,

> If this seems acceptable, the next steps could be ...

I don't think this design works.

Rooms change the semantics of an LWLock: exclusive access no longer
excludes all other holders. Data access needs to be reworked to support
this. The buffer mapping access in this patch already has a problem:
different rooms in the same partition can map to the same hash bucket,
allowing concurrent modifications to its chain and causing entries to be
lost.

In 0001, releasing the last room while LW_FLAG_WAKE_IN_PROGRESS is set
leaves LW_EXCLUSIVE set. Shared waiters cannot clear it and remain
blocked forever unless a subsequent exclusive acquisition and release
clears it. This also affects ordinary LW_EXCLUSIVE acquisitions.

All 26 rooms share one state word. Acquirers of disjoint rooms still
CAS on the same cache line, so the scalability bottleneck remains and
may even get worse. In this case, I would increase NUM_BUFFER_PARTITIONS.

Best regards,
Yuhang Qiu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2026-09-11 10:08:43 Re: PG19: two RI fast-path issues found while testing the batching revert
Previous Message Hayato Kuroda (Fujitsu) 2026-09-11 09:45:34 RE: pg_createsubscriber does not check output_plugin_libraries