Re: Changing shared_buffers without restart

From: Palak Chaturvedi <chaturvedipalak1911(at)gmail(dot)com>
To: Yuhang Qiu <iamqyh(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)databricks(dot)com>, Haoyu Huang <haoyu(dot)huang(at)databricks(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
Subject: Re: Changing shared_buffers without restart
Date: 2026-09-08 11:24:37
Message-ID: CALfch18bfYdXz1E7OZO45ECKN9Sn=L-tYXg=mhWa0b2k3c7Qnw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hey Yuhang,

On Mon, 7 Sept 2026 at 20:09, Yuhang Qiu <iamqyh(at)gmail(dot)com> 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

Attachment Content-Type Size
v20260908-0016-buffermgr-fix-EvictExtraBuffers-BM_TAG_VALID.patch application/octet-stream 1.6 KB
v20260908-0015-shmem-fix-madv-remove-range.patch application/octet-stream 1.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ilya Cherdakov 2026-09-08 11:52:58 Assert in test_bms_membership();
Previous Message Henson Choi 2026-09-08 11:18:35 Re: [SQL/PGQ] Native executor for Graph query