| From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
|---|---|
| To: | Ma Xueting <ma(at)sraoss(dot)co(dot)jp> |
| Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Report no unpinned buffers as insufficient resources |
| Date: | 2026-10-01 11:17:02 |
| Message-ID: | CAEze2Whq4Sgm1ofRdA2=-8QvTO4eYPUau1n1_PyjxTaN79uJ0A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 24 Sept 2026 at 07:26, Ma Xueting <ma(at)sraoss(dot)co(dot)jp> wrote:
>
> Hi,
>
> StrategyGetBuffer() currently reports "no unpinned buffers available"
> using elog(ERROR). As a result, clients receive SQLSTATE XX000
> (internal_error), and the message is not translatable.
>
> Although this condition is uncommon, it can occur in user environments,
> for example when shared_buffers is configured unusually low. GitLab
> encountered this error with a shared_buffers setting of 1 MB:
With the recent drive to read vectorization and AIO, backends are
holding more buffers pinned than ever before, so we've increased the
likelyhood someone will eventually hit this limit. Making the error
message more descriptive is definitely useful.
> The analogous local-buffer error, "no empty local buffer available",
> is already reported using ERRCODE_INSUFFICIENT_RESOURCES.
>
> This patch changes the shared-buffer error to use ereport() with
> ERRCODE_INSUFFICIENT_RESOURCES.
Yep, LGTM.
> I also considered adding a hint suggesting an increase to
> shared_buffers. However, a small shared_buffers setting is not the
> only possible cause of this error, so I left the hint out of this
> version. I'd welcome thoughts on whether such a hint would be useful.
I think it could be useful, but indeed the issue can be caused by
various different issues (misbehaving code leaking buffer pins,
too-high connection counts, bad plans, bad plan nodes, etc.). If
we're adding an errdetail/errhint, then the ereport in
GetLocalVictimBuffer should probably also be updated accordingly.
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Narayanan Venkateswaran | 2026-10-01 11:21:00 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Nisha Moond | 2026-10-01 11:08:40 | Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation |