| From: | Yuhang Qiu <iamqyh(at)gmail(dot)com> |
|---|---|
| To: | Palak Chaturvedi <chaturvedipalak1911(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 03:09:38 |
| Message-ID: | 4E5726E6-D640-4E2E-8860-5A2DDDABC35D@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Could we recheck BM_TAG_VALID under the lock, and unlock and continue
if it is already clear?
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.
Best regards,
Yuhang Qiu
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Guo | 2026-09-08 03:13:08 | Re: Assert failure in try_nestloop_path() |
| Previous Message | Henson Choi | 2026-09-08 02:59:33 | Re: Row pattern recognition |