| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
| Cc: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: GetBufferDescriptor() being called for local buffers from MarkBufferDirtyHint() |
| Date: | 2026-07-03 03:07:21 |
| Message-ID: | akcnadjOV4pv7ESL@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 03, 2026 at 08:17:22AM +0530, Ashutosh Bapat wrote:
> An actual subtle problem does exist in check_temp_buffers. If we set
> NLocBuffer to a non-zero value when LocalBufHash is not initialized,
> it's going to prohibit a change in the GUC. If LocalBufHash allocation
> fails, probably user would like to try again by reducing NLocBuffer.
> The prohibition makes that impossible.
>
> The other such usage in hashbuild() is fine, since it will allocate
> more space if at all.
>
> CheckForLocalBufferLeaks() walks the local buffer descriptor array,
> but it's already initialized when NLocBuffer is set.
Sure, now a lot of this code is also shaped with some internal static
routines, so I'm also slightly afraid of some refactorings. It just
feels like in the long-term setting NLocBuffer earlier makes some of
the assumptions of the code a bit more brittle. Not a bid deal,
still..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-07-03 03:08:03 | Re: GetBufferDescriptor() being called for local buffers from MarkBufferDirtyHint() |
| Previous Message | Fujii Masao | 2026-07-03 02:58:52 | Re: WAL compression setting after PostgreSQL LZ4 default change |