Hey Yuhang, On Mon, 7 Sept 2026 at 20:09, Yuhang Qiu <[email protected]> wrote: > > Hi Palak, > > > Changed both the precheck and the locked assertion to BM_TAG_VALID > > I missed a race in my earlier suggestion. Restricting new allocations > does not prevent another backend from invalidating an existing buffer. > For example, DROP TABLE can clear the tag between the unlocked precheck > and LockBufHdr(), causing the assertion to fail. >
Reproduced this. I added a test-only injection point right after DROP TABLE clears BM_TAG_VALID but before EvictExtraBuffers() takes LockBufHdr(), and the assertion trips every time. Also found it independently while running the stress tests, 6 hits, all TRAP on the BM_TAG_VALID assertion. > Could we recheck BM_TAG_VALID under the lock, and unlock and continue > if it is already clear? > Yes. v20260908-0016 rechecks BM_TAG_VALID under LockBufHdr() and does UnlockBufHdr() + continue instead of asserting when the tag was cleared concurrently. > Also, the earlier comment in 0012 still says "We do not consider the > current end of the structure". That is no longer true for shrinking. > Right, that line predates the MADV_REMOVE range fix. Removed it in v20260908-0015. Thanks, Palak
v20260908-0016-buffermgr-fix-EvictExtraBuffers-BM_TAG_VALID.patch
Description: Binary data
v20260908-0015-shmem-fix-madv-remove-range.patch
Description: Binary data
