| From: | Tomas Vondra <tomas(at)vondra(dot)me> |
|---|---|
| To: | Aleš Zelený <zeleny(dot)ales(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PostgreSQL 17.5 - could not map dynamic shared memory segment |
| Date: | 2025-06-21 22:44:36 |
| Message-ID: | 61bb2e7f-9c29-4c3f-a316-60780ce5512a@vondra.me |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 6/21/25 23:09, Aleš Zelený wrote:
> Hello,
> ...
>
> The application benefits from parallel queries, so despite the first
> temptation to disable parallel queries (based on log entries correlation
> only, but is that the root cause?) I did not want to disable parallel
> queries, if there is another workaround/solution/fix available.
>
> Thanks for any hints on how to provide more information if needed, as
> well as for fix/workaround advice.
>
Could it be that you simply ran out of memory, or perhaps hit the
overcommit? What does sysctl say?
sysctl vm.overcommit_memory
And what's CommitLimit/Committed_AS in /proc/meminfo? IIRC the shmem is
counted against the limit, and if the system does not have significant
swap, it's not uncommon to hit that (esp. with overcommit_memory=2).
regards
--
Tomas Vondra
| From | Date | Subject | |
|---|---|---|---|
| Next Message | César Muñoz | 2025-06-22 18:07:06 | Memory overhead of a large number of partitions in the same table |
| Previous Message | Aleš Zelený | 2025-06-21 21:09:49 | PostgreSQL 17.5 - could not map dynamic shared memory segment |