| From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Thom Brown <thom(at)linux(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jack Ng <Jack(dot)Ng(at)huawei(dot)com>, Ni Ku <jakkuniku(at)gmail(dot)com> |
| Subject: | Re: Changing shared_buffers without restart |
| Date: | 2025-07-14 14:39:33 |
| Message-ID: | y3dv2iuwh7tai5pztshiezdtffpfzt6t3nj4vbs6jmywhyy4zo@wxqvktyq5ix5 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Mon, Jul 14, 2025 at 10:23:23AM -0400, Andres Freund wrote:
> > Those steps are separated in time, and I'm currently trying to understand
> > what are the consequences of performing them in different order and whether
> > there are possible concurrency issues under various scenarios. Does this
> > make more sense, or still not?
>
> I still don't understand why it'd ever make sense to put a buffer onto the
> freelist before updating NBuffers first.
Depending on how NBuffers is updated, different backends may have
different value of NBuffers for a short time frame. In that case a
scenario I'm trying to address is when one backend with the new NBuffers
value allocates a new buffer and puts it into the buffer lookup table,
where it could become reachable by another backend, which still has the
old NBuffer value. Correct me if I'm wrong, but initializing buffer
headers + updating NBuffers means clock sweep can now return one of
those new buffers, opening the scenario above, right?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Dolgov | 2025-07-14 14:43:22 | Re: Changing shared_buffers without restart |
| Previous Message | Aleksander Alekseev | 2025-07-14 14:34:40 | Re: pg_overexplain extension name |